I'm a strong supporter of 2FA and we implemented it some time ago on Report URI. All users can use 2FA on their account for free, whether they pay for a subscription or not, and it represents a great way to boost the security of your account. However, problem does arise if you lose your 2FA token and your recovery code. What do we do in that scenario?




2FA on Report URI

Setting up 2FA on your Report URI account is a similar process to most sites so I will give a quick tour of the process. Once you have an account head over to the Settings page and you can see the 2FA setup section.



All you need to do is scan the 2FA QR code with an app of your choice, I prefer and use Authy, and enter the 6 digit code it presents back into the site. Once that's complete you then have 2FA setup on your account and you must always enter a code at login. If you can't enter a code at login, say because you lost your phone and didn't have backups enabled, you'd need to use your recovery code. After enabling 2FA on your account you get to make note of your recovery code.



If you lose your app, phone or the ability to generate codes in some way, this is the only thing that will save you. This code will disable 2FA on your account and as the message says this really is the only way to get back into your account in the event you can't generate codes. Here is the problem.


Account recovery

We have quite a large amount of users on Report URI and 14.47% of them have 2FA enabled on their accounts. This is a great security precaution and I'm happy to see such a high % of users using 2FA, although I would like it to be a lot higher. The problem arises when one or more of those users loses their ability to login because they've lost their ability to generate codes and don't have their backup token. To avoid this problem I have my backup code saved in my password manager, 1Password, and I have the backup option enabled in Authy so if I ever lose or damage my device I should be able to restore it. That said, it does happen, people lose the ability to generate codes and their backup recovery code, and it has happened. Inevitably I've had users reach out in this situation and it does represent a bit of a problem. Some users understand the predicament this places us in as service provider and other users are really.. insistent.. that we find some way to allow them back into their account.

In this situation we have never let a user regain access to their Report URI account.

To me this is exactly how 2FA should work. If you can't generate the 6 digit code or present the recovery code then you should not be able to access the account even with the email address and password. This is the very essence of 2FA at work. Other services do have other means to do account recovery but I feel that a lot of those options weaken the value of 2FA. We also don't have that option available to us because we intentionally don't collect any additional data about our users. We have your email address and that's it, there's no additional information for us to verify about you. This left me with only one option for those that find themselves in this situation.



Account deletion

If a user finds themselves in this situation the only viable solution we have come up with is to offer them the ability to request deletion of their account. With a request from the registered email address of the account we can delete all data associated with it and the user can then register again and setup a new account. This option keeps the value of 2FA, in that no one without the 2FA codes gained access to the account or the data in it, and maintains at least some convenience for the user as they can now register again with the same email address.

Most users seem happy with this solution and understand the reasons why this is the only option we've been prepared to offer. I'm open to suggestions that this isn't the best course of action and writing this blog is in large part because I wanted to explain our process and get feedback on it. Thoughts and ideas are welcome in the comments below.