Account recovery protocol when email is breached, or inaccessible?

Question

I am creating a web application for individual accounts. The email address is also used as the user name. 2FA is setup for the user to optionally use. I've been trying to wrap my head around preparing for account recovery in these couple of scenarios:

• A user hasn't logged in the website in a while and no longer has access to their email account, and they also forgot their password.

• A user's email is breached, and the hacker/bad actor comes across some emails related to the website. Worst case scenario, they go to the website and reset the password using the forgot password feature, and then change the email address.

For the first scenario, if a user no longer has access to the email or maybe doesn't even know the email they used, how can I properly authenticate that they are who they say they are? I'm currently tracking a history of email changes, and the last three password hashes used.

For the second scenario, here is the approach I am considering, but not sure of:

• Anytime a password or email is changed for the first time in the last 24hrs (using 24hrs as an example), store the original Email(Username) and password hash with a timestamp in a database table.
• If the email or password is changed again and the 24hrs isn't up yet, the original stored email and password will remain.
• Send an email anytime the password is changed, reminding user if they don't recognize this change to immediately use the password reset feature and reset their password.
• When an email is changed successfully, send an alert to the original email notifying of the change. Also, allow the user to recover their account using their last know login credentials within 24hrs if they do not recognize this change. This is where the stored email and pw hash will be used as long as the user attempts recovery within 24hrs. So even if the hacker managed to change the email and password, the original user could still recover their account (within 24hrs) and gain control back.

I would like to add, the site is still in development and has no users, so I am trying to sort this out early on. I also don't have much of a budget currently, so using SMS verification isn't something I can use unfortunately to start out with.

Answer 1

If you want users to be able to recover their account when they no longer have access to their e-mail address and forgot their password, you can introduce alternative authentication methods like the following:

• a recovery passphrase consisting of actual words which may be easier to remember than the original password chosen by the user
• a randomly generated token which the user is supposed to download or print out and store somewhere safe
• a backup file containing random or encrypted data which can be uploaded to regain access to an account

Of course all of this only makes sense if the user takes account recovery seriously and keeps the data both safe and accessible. You should include detailed instructions on why the data is important and what the user is supposed to do with it. Additionally, you should recommend the use of a password manager. This not only solves the underlying problem (forgetting passwords), but it's crucial for generating and safely storing strong passwords.

As to the second scenario (recovering from a breach of the e-mail account), I strongly recommend against interfering with e-mail or password changes. If the system automatically restores a previous e-mail address or password, this may help against changes caused by an attacker. But it might as well sabotage a legitimate user who wants to do those changes to protect the account from an e-mail account they've lost control over or a password that has been leaked. In other words, you cannot assume that the old credentials are still valid and the new ones possibly attacker-controlled -- it might be the other way round.

Use a straightforward procedure without any loopholes.

• If the user wants to change their e-mail address and can authenticate with their password, you should accept that and not give the owner of the previous address any veto rights. The old e-mail address address may be controlled by somebody else now. At most, send an informational mail to the previous address.
• If the user wants to change their password and can show control of the e-mail address (by clicking on a I-forgot-my-password link), you should also accept that and not allow the use of the previous password which may be compromised now.
• If the user has lost both access to the e-mail address and forgot their password, or if the account has been taken over by an attacker, then the recovery methods mentioned above (passphrase, random token etc.) could be used to regain control.

Answer 2

This is a good place for a risk analysis based on your website. The traditional approach to this would be to use security questions.

It's possible to have Good Security Questions, however NIST does consider security questions as insecure, so they should only be utilized as secondary verification if your potential impact from an account compromise is high.

However, unless your website is based around highly sensitive or user-specific data (such as banking or financial websites), and you thus have additional info you can validate, it's generally appropriate to consider that if their email account is compromised then the associated accounts are compromised.

Sending appropriate notifications to the email addresses (including old and new) if emails are changed and passwords are reset is a good way to help mitigate this.

Answer 3

I run a non-security critical website and it is optional to use 2FA. I thought I'd answer this question based on my own choices for my use case. Email and password are considered the same factor since a password is oftentimes all that is needed to gain control of the email address. I think email should be slightly more trusted for my use case since the email is often seen as the centre of ones online presence. It's unlikely that the user cares more about the security of an account on a random web page than the security of their email account (though too many probably won't care about that one either). 2FA is optional to activate and the user is also given a generated long-term secret on sign-up that they can choose to save and store somewhere safely. The long-term secret is optional and can be deactivated if desired.

With 2FA activated:
Password reset and email address change is straight forward. Just provide password or email as well as the 2FA factor to confirm it.

Without 2FA activated:
If the user request a password change they need to provide their current password. If they request a password reset in the case of a forgotten password, they are asked to confirm it with their email. If they want to change their email address, they are also asked to confirm it with their current email address.

If both email address and password are unavailable:
The long-term secret mentioned in the first paragraph is more trusted than both password and email, and can be used to reset both (2FA confirmation is also needed, if activated). Both email and password (or either along with 2FA confirmation, if activated) is needed to reset the long-term secret.

If the user can't provide a password, email confirmation, 2FA confirmation, or the long-term secret code, then we have nothing to trust that the user is who they say they are.

Other options:
If you collect a phone number from the user, this could be used as a second factor. This might not be considered as secure since I think SIM-stealing and similar attacks are still fairly common, but at least a user is probably less likely to change phone numbers or lose access to it compared to an email address. And I would consider this a separate factor from password and email, since you oftentimes can't get access to a phone number using just a password.

You could use the IP address the user connects from as a second factor. This isn't entirely secure either since many devices could share an IP address in some cases, but could be used alongside other factors.

And maybe your application collects other data that could be useful to build greater certainty in the user's identity. Maybe fingerprinting the devices or usage patterns or anything else.

A combination of other factors such as these could be used in cases when the primary factors are missing. But care must be taken here to make sure this is not a much weaker way to authenticate than any of the regular options.