Going Passwordless With WebAuthn
In 2021, the most common password was 123456, and the second most common was 123456789. The top ten list also contains qwerty and password. These passwords are extremely easy to guess and easy to figure out, even if they are hashed.
Most people will use the same password across several different web apps, making many of their online accounts vulnerable to attack. If one web app is compromised and the password leaked, the attacker could access user accounts across many more web apps.
These issues combined are driving efforts toward a passwordless approach to modern application sign-on. Leading this charge is WebAuthn, a standard for achieving a secure, passwordless login. The resistance to phishing attacks is another aspect that puts WebAuthn ahead of other passwordless options such as One Time Passwords (OTP) and magic email links. WebAuthn also lends itself nicely as an additional factor in a Multi-Factor Authentication (MFA) configuration.
How WebAuthn Works
The Web Authentication API, or WebAuthn for short, is a specification maintained by W3C and the FIDO alliance. It uses Public Key Infrastructure (PKI) as its foundation. In PKI, instead of using a password for a web app, a public/private key pair is created. The web app holds the public key, and the private key can be stored in a device the user controls. This device could, for example, be the crypto module on a computer or mobile device or a physical key like a YubiKey. The keypair is unique for each web app, and as such, does not work with a different web app. This makes WebAuthn very resistant to phishing attacks wherein credentials are captured via a malicious app and then used for access in the actual app.
The private key stored on a device could also be protected by a PIN. At first glance, this may seem like just another password protecting the private key. However, there's a big difference here. The server-side part, i.e., the web app, doesn't store a password used for verification. Instead, it holds the public key, and the public key in and of itself is useless unless you also have the private key. With this approach, the vulnerability of leaked passwords has already been mitigated. Someone can still figure out the PIN for the device that holds the private key, but they must also obtain the physical device. This is highly unlikely, and if it were to happen, it would probably be an extremely targeted attack. This is why we all have short PIN codes for ATM cards — it's improbable that both the card and PIN will be stolen for a large portion of the user base.
Registration
The registration process is pretty straightforward for a consumer that uses hardware to store the private key and leverages WebAuthn for login. There is a separate registration process for each app generating the public/private keypair.
In an enterprise environment where a centralized authorization server is utilized, this might look a bit different. Naturally, a registration step could occur the first time a user logs in and the authorization server is involved. After that initial step, the public key is stored by the authorization server and can be used across web apps that leverage the authorization server.
It would also be possible to have a centralized, out-of-band process for pre-registering devices for employees before they are handed out. This way, the login process for users is seamless right from the beginning, and pairing the device to a particular person is performed in a more controlled manner.
Logging In
In a simplified way, the login process will result in the authentication process producing a large random number, also referred to as the challenge. This challenge is hashed using the private key that the user holds. This would first involve unlocking the secure store where the private key resides (potentially using a PIN or a fingerprint, for example). The hashed challenge is then sent to the web app to validate using the stored public key. Thereby, it proves the user is who they say they are since they are in possession of the correct private key.
WebAuthn in the Curity Identity Server
The Curity Identity Server supports WebAuthn out-of-the-box. The authenticator can be configured and used with, for example, Apple TouchID, YubiKey, or other devices supporting WebAuthn.
The WebAuthn Authenticator is straightforward to configure and can cover many different scenarios as it relies on a device that supports the WebAuthn standard.
Conclusion
In summary, some of the main benefits of WebAuthn include:
No need to handle secure storage of passwords.
No password needs to be passed from component to component, removing the complexity of securing that process.
Breached web apps will not impact other apps since the public key is unique for each app. WebAuthn removes the "same password everywhere" problem.
Enables passwordless authentication and can also be used as an additional factor for MFA.
Phishing resistant by tying the key to a particular server verified by the browser before allowing its use.
Additional Resources
If you want to learn more about WebAuthn, here are some useful resources:
A recording showing authentication using a
Webinar
Phishing Resistant Passwordless Authentication with Curity and Yubico
