The factors we choose
As most of us know by now, there is always more than one way in: to an app, to a website, to your house.
That sign in page with the username and password prompt? It’s just the digital equivalent of the front door. But guess what? There’s also a back entrance, a garage door, and when all else fails a shady locksmith who only wants your mother’s maiden name.
Today’s sign in and recovery methods
Most apps and websites today provide sign in by prompting for a username and password. Many sites including most major email, social media and personal financial sites also offer one or more additional multi-factor authentication (MFA) methods based on a phone call, a text to a mobile phone, or a mobile authenticator app, for example.
If you have forgotten your username and/or password, usually you can click a link and get back into your account based on an email, “security questions” you configured when you setup the account, or recovery codes. MFA methods such as text or mobile app can be used for this as well.
Fortunately and unfortunately, these recovery mechanisms provide an alternative path to sign in. Malicious hackers can choose which access path is easier: sign in or account recovery. Instead of trying to figure out your password, they may figure out answers to your security questions, hack into your email accounts, or socially engineer cell phone service providers into redirecting service for your phone number to a phone they control. They then use these methods to access and take over your account, resetting your password.
The good news is that the set of sign on and recovery mechanisms available is evolving from predominantly password and text, to include much more secure factors such as security keys, phones and computers using WebAuthn/FIDO2 credentials.
| Pre-shared symmetric secrets (least secure) | Enrolled factors, non-key based (more secure) | Public/private key-based methods (most secure) |
|---|---|---|
| Passwords | SMS text to phone | FIDO2/Webauthn platform credential |
| Security questions | Email code or temp link | FIDO2/Webauthn security key |
| Recovery codes | Phone call | Phone app with key pair |
| Mobile app OTP code | PKI Smart Card |
In order to gain the most value from this evolution, we need to update both sign in and account recovery experiences to use multiple, secure factors.
What websites should do in the near future
In the near term, the number of sites that support MFA will continue to increase, and some will adopt non-password factors as primary authentication, as for example the site medium.com has done with their email-based sign in. Because of this, the “I forgot my password” experience will need to broaden to encompass loss of other factors, for example, “I lost access to my email”, “I lost my phone and can’t use a text or phone app”, “I lost my security key”, or simply “I’m having trouble getting into my account”. Authenticator apps themselves may help by providing backup capabilities, however resources need to account for the possibility that no backup exists, either because the user did not create one or because the authentication method itself did not easily lend itself to backups (such as private key based methods). In short, “sign in” and “recovery” experiences should be offered for each factor. If sign in requires two factors, recovery should have an equivalent or higher bar
From a security perspective, account recovery should be seen as just another sign in method, as this is the way hackers see it. Strong auth doesn’t mean much if account recovery is weak.
What sites should be thinking about for the future
In the future, the user experience for signing in will converge with the experience for account “recovery” in that the user will be asked to provide whatever factors are most optimal given their device and scenario. There will be a graded scale of factors, where “not all factors are equal”. For example, proof of possession of an asymmetric private key will be considered more secure than providing a symmetric key or password. Multiple credentials / keys from different sources will be considered more secure than a single factor, and request context (risk level based on IP address, request info, device info, etc) can be incorporated into an overall risk score that serves as a factor.
Importantly, a single factor that is stronger, such as a security key, should not be recoverable based on a single factor that is weaker, such as a password or security questions. More generally, if a user needs n factors to sign in, resources should ensure at minimum that users have at least n + 1 factors registered, and ideally should ensure that users have registered additional factors of equivalent or greater strength, to enable recovery without lessening security.
And lastly a reminder from “Principles”:
Finally, new users or users who do not succeed in the account recovery experience need a way to create a new account or to appeal access to their existing account. Good auth anticipates these needs and provides entry points into these experiences, including an experience for when all credentials are lost.
Implementation ideas
In order to make this new world a reality, resources and identity providers should build features and experiences such as the following:
Basics
Provide support for additional factors for sign in, not just passwords
Provide a recovery experience for each sign-in factor
Help users enroll for additional factors to enable recovery
Expand options and policies for non-password sign in / account recovery
Provide sign in with single, non-password factor such as a phone app or security key
Provide recovery via security keys in addition to phone apps, email, and other less secure factors such as knowledge-based questions. For less secure factors, require multiple factors for account recovery.
For enterprise identity providers
Provide configurable policy to determine how many and which factors are sufficient to reset each factor, while enforcing some baseline criteria
Provide configurable policy to govern how often factors are re-verified
Provide policies to allow configuration of which factors users can use for what (for example, accessing resources vs managing auth factors)
Provide configurable policy rules for enrolling new factor(s)