This article is an opinion piece geared toward (re)evaluating your thinking about end-user workflows for account recovery in traditional web authentication systems. Leaving aside superior PKI-based authentication schemes such as FIDO for a moment, let’s take a look at how account recovery scenarios on a traditional website might be made less attractive to attackers attempting account takeover.

It is no secret that account recovery flows such as “Forgot Password” or “Forgot Username” implemented on many sites provide an attack vector for a hacker to attempt account takeover. Account takeover is just another way of saying “login as someone else”, and that’s just really another way of saying “login”. It stands to reason then that account recovery is really just an alternative way of logging into an account. It differs from whatever is considered the “normal” login process only in that it is often more onerous because some form of not-often-used or perhaps inconvenient technique is used to try to establish that the user operating the browser is who they say they are. Account recovery techniques also tend to focus on methods that do not rely solely on human memory – chances are that the reason a legitimate user initiates account recovery is because they’ve forgotten something like a password they were supposed to remember. So let’s take a look at account recovery in the context of it just being another way to login, and see if that changes our thinking on what your site might offer…

Common Current Practices

Some sites simply send a one-time link to your registered email address to facilitate account recovery. Others, particularly the large consumer-facing social providers go out of their way to both provide and encourage the registration of multiple different digital means of authentication so as to avoid any need to do in-person style identity proofing for account recovery. Other sites (e.g. your bank) may require an in-person interview at a branch to do account recovery. At the branch they may use a similar document-based identity proofing mechanism to that used to establish your account in the first place.

The options offered will vary from site to site based on business risk and operational necessity. For example if gmail is your preferred/only email provider, and access to gmail is protected with your Google account, there’s no point in providing only a one-time email link recovery mechanism for Gmail. Make no mistake though – ALL these techniques from digital workflows to in-person interviews are just alternative forms of authentication to your account.

So let’s explore some of the common techniques and see what the implications are… and also let’s stop calling it account recovery, and call it for what it is – another form of account authentication. Further let’s now understand that for all practical purposes *all forms* of authentication on their own, including those used for account recovery, offer the same level of access to your account and therefore are considered to be equally important in terms of their security properties.

Email OTP

Sending a link to an email address allowing password reset is a common pattern. Sometimes (as with Gmail) this can be an alternative recovery email address separate from the primary email addressed used with the account. What you are really doing with this technique is making your account authentication as strong as whatever the authentication is to your users’ email. This varies WILDLY in the email market – from strong multi-factor authentication right down to anonymous email (think Gorilla mail, mailinator, etc). Unless you are in a controlled intranet-style environment (in which case you can probably use management hierarchy to easily perform account recovery via a trusted manager/employee relationship), this is really an awful way to secure an account on its own – particularly if you hold any kind of liability for the consequences of customer account takeover. It’s also easy though, and you see it in lots of places.

When used remember this: Access to the email account is access to login, plain and simple. If you have no control over email access you’ve really just delegated strength of authentication to something you don’t know. Only the knowledge and intelligence of the end-user decides if the account has any real protection. Chances are most users will have no clue.

SMS OTP

Sending an OTP to a registered mobile phone number is also common. Most often it is seen in second-factor authentication scenarios, but is also used in account recovery scenarios and is therefore a means of login. There are plenty of publicly documented examples of SIM swapping (convincing someone from the telco you’ve lost your phone and porting your number to a new SIM) – enough that this is not a recommended practice. Similar to email OTP however it is easy, and therefore quite commonly implemented.

Backup Codes

I think this is one of the first things I enabled on my Google account – a long time ago now. These are really alternative passwords for your account that can be used once each. One interesting facet of backup codes is that they are not human-selected so tend to have better entropy than your average password. You’re supposed to print / save a list of 10 or so, and keep them in a safe place. Rate limiting, CAPTCHA and temporary account locking are generally employed to limit an attackers ability to brute force your backup codes, but this can also provide a denial of service (DoS) vector for a disruptive attack on an account depending on how the provider chooses to respond to failed attempts.

This technique works ok, but is quite inconvenient and still quite a lot of work for a website to deploy properly. It also requires users to store them in a safe place – if people were good at doing this, they probably would not have forgotten their password in the first place.

Knowledge Questions

Most people are familiar with these – and their pitfalls. Often the answers are readily discoverable via social media or other PII leaked and available on the dark web. Not an ideal login mechanism for high value accounts. A smart user would use fake questions and answers, with different combinations for every site. This is very inconvenient and non-obvious and almost never done by normal people. Because it is used infrequently, people also have a habit of not remembering the exact answers they gave, or using poor answers that are weaker than a password. This is really not a very good login mechanism, and whilst still in widespread use it is not an encouraged best-practice.

I still use traditional second-factor authentication technologies – so what should my site do for account recovery?

Good question – what works best for your site and your users will depend a lot on the relationship you have with them, and what your risk tolerance is for account takeover. Do you even know who your users really are at all? In some cases such as B2E deployments and traditional brick and mortar banks this may be “yes”. In such circumstances true account recovery may be done in person or via a trusted person relationship (e.g. manager to employee). This is generally the best case scenario.

In a purely digital B2C space where there is no real in-person identity proofing performed, my current recommendation is to offer and in fact demand registration into multiple forms of second-factor authentication, and when performing account recovery require more than one of the second-factor mechanisms as part of the recovery process.

For example, despite their various pitfalls mentioned above, let’s say you have a current multi-factor environment which offers password login followed by conditional email OTP, SMS OTP, and perhaps mobile push authentication. A user indicates they have forgotten their password. Now what?

Well, let’s assume your normal approach would be to permit password reset via a short-lived email-OTP link. Upon successful presentation of the email-OTP link, and before any password reset occurs, your site should immediately demand 2FA with another mechanism OTHER THAN email OTP. In this way you are still employing multi-factor authentication even in the face of one of those factors not being the originally forgotten password. Only after that second non-email-OTP challenge is satisfied should the password reset operation be allowed to complete.

Again: What you are really doing is still performing multi-factor authentication using two different factors where neither of them happen to be a password.

Also, when events like this occur, simultaneously notify the user of this unusual form of account access via a trusted out of band communications channel such that they can inform you if the account access attempt was genuine or fraudulent.

This is not a perfect approach – there is no such thing as a perfect approach, but making it difficult for a would-be hacker to perform account takeover is definitely a step in the right direction. Thinking of your account recovery process as just another form of account authentication allows you to see that the same conditional two-factor mentality that you apply to regular account authentication should be used to deal with account recovery scenarios as well.