Making Passwordless Fallback Systems
Passwordless authentication is an authentication method in which a user can log in to a computer system without the entering (and having to remember) a password or any other knowledge-based secret. Passwordless authentication methods typically rely on public-key cryptography infrastructure where the public key is provided during registration to the authenticating service (remote server, application or website) while the private key is kept on a user’s device (PC, smartphone or an external security token) and can be accessed only by providing a biometric signature or another authentication factor which is not knowledge-based.
Today’s Passwordless still has Passwords
While passwordless authentication offers many benefits such as improved security, reduced risk of compromise, lower IT costs, and better user experience, it is not yet a perfect solution. One of the main challenges of passwordless authentication is how to handle fallback scenarios when the primary authentication method fails or is unavailable. For example, what if the user loses their device, forgets their PIN, or their biometric sensor malfunctions? How can they still access their account without compromising security or convenience?
Many passwordless authentication systems still rely on passwords as a fallback option in case of emergency. This means that users still have to create and remember passwords, which defeats the purpose of going passwordless. Moreover, passwords are often the weakest link in the security chain, as they can be easily guessed, stolen, or phished by attackers. Therefore, using passwords as a fallback option undermines the security benefits of passwordless authentication and exposes users to potential breaches.
Fallback Authentication Methods
To achieve true passwordless authentication, we need to consider alternative fallback methods that do not involve passwords or knowledge-based secrets. Some of the possible fallback methods are:
Secondary device or account: The user can verify their identity by using another device or account that they own and have registered with the authenticating service. For example, the user can receive a one-time code or a push notification on their phone or email that they can use to log in to their account on another device. This method requires the user to have access to another device or account that they trust and that is secure.
Recovery codes: The user can generate and store a set of recovery codes that they can use to log in to their account in case of emergency. The recovery codes are randomly generated and are valid for one-time use only. The user has to keep the recovery codes in a safe place and not share them with anyone. This method requires the user to be careful and responsible with their recovery codes and not lose them or expose them to others.
Trusted contacts: The user can designate a set of trusted contacts (such as friends, family members, or colleagues) who can help them recover their account in case of emergency. The trusted contacts have to verify their identity and consent to help the user before they can receive a recovery code or a link that they can share with the user. The user has to trust their contacts and ensure that they are available and willing to help when needed. This method requires the user to have a network of reliable and trustworthy people who can assist them.
Moving Towards True Passwordless
Passwordless authentication is the future of secure and convenient access management, but it is not without its challenges. Fallback scenarios are inevitable and need to be addressed with care and creativity. Using passwords as a fallback option is not only counterproductive but also risky and inefficient. Therefore, we need to explore and implement alternative fallback methods that do not rely on passwords or knowledge-based secrets. By doing so, we can achieve true passwordless authentication and enjoy its full benefits.