Authentication systems are built for humans and unfortunately humans lose and forget things. Adding multi-factor authentication (MFA) can increase the likelihood of being locked due to the additional steps it takes. To complicate things, people continue to do a lot more business online, which also means more fraud and more money lost to account takeovers. This is why account recovery is such an important part of any robust authentication system.
From password resets to complete account lockout, you want to ensure that your business is adequately protecting your customers. The recommendations in this post focus on consumer account recovery because you likely won't have the same level of control over end users as an enterprise solution.
Authentication requirements for account recovery
"Account recovery is, in essence, a bypass of the main account security protocols, and therefore should be treated as an alternative authentication system." Mark Loveless, Decipher Magazine
Account recovery is risky because you're not just authenticating, you're reproving an identity. It's not an identity that comes with a clean slate since the existing account likely has data or money attached to it. Because there are additional risks associated with account recovery, companies spend an estimated $40-$70 per support call to unlock an account.
The three main requirements for recovery methods include:
- Long-term memorability or access
- Slower authentication time is okay
- Widely usable solution
The requirements for account recovery methods are slightly different from classic authentication. Since recovery doesn’t happen very often, recovery methods must be accessible without the constant "rehearsal" of other methods. Because it’s more rare, these methods can be slower than an everyday login.
These methods also need to be usable, since account recovery is something most people will do. Research shows "a nearly linear relation between the time passed and the number of users who used the fallback system." After 18 months almost 70% of Google's users had done a basic account recovery.
Options for account recovery
The more options your application registers for an already authenticated user, the more options the user will have to safely and quickly regain access to their account – even if they aren't using all of these options every time they sign in.
|Examples||Passwords, security questions, account details|
|Pros||Common, easy to implement, easy to onboard|
|Cons||Answers can be leaked, researched, or guessed. Humans are forgetful|
Some knowledge options are better than others. NIST no longer recommends security questions as an acceptable authentication method since they can often be researched or guessed.
Alternative options might include asking the user for account details like recent transaction history or when they recently called support.
|Examples||Mobile phone, backup codes, WebAuthn, Passkeys|
|Pros||Can use common devices, some are not phishable|
|Cons||Humans lose and replace things, harder to set up|
Possession factors, or something you have, tend to be more secure than passwords because they can be harder to phish and don't get leaked in data breaches.
One possession method we see a lot for account recovery is backup tokens or recovery codes. These codes are given to you, so they're more likely to be longer than a user-generated PIN and less likely to be reused, making them more secure than passwords.
However, that means that people have to store backup codes somewhere and while I've met people who dutifully print them out and store them in their home safe (really), users can easily lose access to these codes by the time they need one.
Luckily, experience tells us that backup codes do work. In one large customer, we saw that 1% of second-factor authentications each week used recovery tokens. 1% might not seem like a lot, but when the customer is doing many thousands of authentications each week, this allows hundreds of users to access their accounts without going through customer support or incurring a waiting period which is good for both the customer and the business.
Passkeys are a new standardized, passwordless authentication solution trying to solve the usability and account recovery challenges of WebAuthn. Because the Passkey implementation syncs private keys in the cloud, users can use a strong form of authentication across devices without the hassle of explicitly registering each device. This means that Passkeys have a form of built-in account recovery and "provides convenience and redundancy in case of loss of a single device."
Passkeys aren't yet widely supported and may still rely on fallback methods like usernames and passwords in the case of lost devices.
|Examples||Apple "recovery contacts", Facebook "trusted contacts"|
|Pros||Built in social graph in certain companies, can't lose or forget|
|Cons||Works best for already "social" companies|
If your application has the notion of existing user relationships, you can use that to your advantage for account recovery. Facebook lets users set up trusted contacts that provide snippets of a larger security key in the case of an account lockout. Apple supports recovery contacts that can vouch for you.
This is a great idea for social applications but may not be ideal for companies building a social graph just for account recovery. In one study, researchers found that users were creating fake email addresses for their recovery contacts which defeats the purpose of third-party verification.
Recommendations for account recovery
"There is no definitive "best way" to do this, and what is appropriate will vary hugely based on the security of the application, and also the level of control over the users" - OWASP Multifactor Authentication Cheat Sheet
As OWASP notes, there isn't one right answer for account recovery. Think about what makes sense for your business and users, you don't need to follow every recommendation here.
Require users to register additional authentication methods
The best thing you can do is have users register more authentication methods than they need for everyday login.
Your application then has additional, trusted methods to validate when a user loses access to one of the main log in methods. The more methods, the more confident you can be that it's the right person trying to gain access to their account and the higher chance that the user will still have access to at least two factors or steps.
You could register these at sign up or during a different authenticated session.
Design your recovery process based on the value your business is protecting
"An online fantasy game is very different from a retirement account. The [company] must select the appropriate choice between security and customer friction." FIDO notes.
If you're in a higher value industry like financial services, this could mean adding more friction to your recovery process. A user signing up for Gemini, a cryptocurrency exchange, probably is willing to opt in to more security measures than they would for something like an online streaming service.
Force users to complete one successful MFA before enabling MFA
Designing your MFA onboarding well is also really important. According to a 2018 study that focused on the usability of Yubikeys, researchers found that setup success varied greatly depending on the platform they were using. 83% of Google users successfully set up their Yubikey compared to only 32% of Facebook users. 19% of people locked themselves out of Windows 10 because the system allowed them to enable the factor without ever doing a successful verification.
A lot has changed since 2018, but this study is an interesting look at how onboarding UX impacts users' success.
Remind users about recovery options
Prompt users to confirm account information that could be used for recovery when they log in. This helps ensure that those backup methods are still relevant. These types of reminders are relatively cheap and easy to implement, especially compared to the cost of a customer lockout and a support call.
Holidays and new iPhone releases mean a lot of users changing devices. Be proactive about these types of reminders and issue them when you might expect your users to change phones.
Add waiting periods for sensitive recoveries
Finally, we recommend adding a waiting period to deter hackers and give real users time to dispute takeover attempts. Remember that your solution will never perfectly prevent attacks, but in most cases you're trying to build something that will discourage people from trying. The goal is to slow down an attacker so you have time to respond and protect legitimate users.
Companies like GitHub, Cloudflare, Authy, and Gemini publicly state that account recovery may involve up to a 5 day waiting period, so don't be afraid to add one to your process for the most sensitive account recoveries.
Don't deactivate MFA on account recovery
In order to make offering multi-factor authentication worthwhile, use at least two steps in your account recovery process as well. A user may have only lost access to one of the factors, as I had in this case.
Don't give up on MFA
Account recovery is hard, but don't let the challenges discourage you from offering stronger authentication in the form of MFA for your users. Google research shows that even SMS codes help prevent 76% of targeted attacks. That's really good coverage and can protect a lot of people from account takeover.
I hope this has given you some ideas for how to think about your account recovery processes. Twilio's Verify API offers multi-channel solutions from SMS one-time passcodes to in-app push authentication. Learn more about Verify or get started building today. I can't wait to see what you build and secure!