Skip navigation
Duo Blog
Admin Login

Categories & Archive

Administrator’s Guide Part 1: Passwordless is Not Multi-Factorless
Duo Labs
Jeremy Erickson

Administrator’s Guide, Part 1: Passwordless is Not Multi-Factorless

Part of our Administrator's Guide to Passwordless blog series

 

If you go by just the name, “Passwordless” could refer to any login experience that doesn’t require a password. An absurd example would be one that simply logs you in using a username, and nothing else. In considering a passwordless solution, we want to raise the security bar, not lower it. Part of ensuring that passwordless authentication is just as secure as multi-factor is ensuring that it is multi-factor.

In the WebAuthn protocol, there are three primary actors:

  1. The website, also known as the Relying Party or RP

  2. The browser, also known as the Client

  3. The Authenticator, of which some popular varieties include Windows Hello, Touch ID, and security keys like the Yubikey.

 

An authenticator is a device that can generate and securely hold a cryptographic key that serves to identify an end-user. During account registration, the authenticator generates a credential and passes the corresponding public key to the website for association with the user account. Later, during login, the authenticator uses the private key associated with that credential to sign a message known as an assertion, and passes it to the website. The website uses the credential public key, from the registration step, to verify the signature on the assertion. This verification proves control over the credential, which, if properly protected, strongly identifies the authenticator device (and, by extension, the user).

But how do we know that it’s really our user that holds the credential and not an imposter? For instance, someone who stole the authenticator device. For that, WebAuthn and CTAP2 support a User Verification (UV) flag, wherein the authenticator device must first locally verify the identity of the user before it can unlock the credential to sign messages. This often takes the form of a biometric check, such as a fingerprint or face scan. Alternatively, users can unlock the credential using a local PIN. Notably, the biometric or PIN never gets sent to a server or otherwise leaves the device.

Since User Verification generally can only be performed locally, attacks against this user verification process become very labor-intensive and must be targeted at specific users, greatly increasing the difficulty of attacks.

In the WebAuthn protocol, the two factors are:

  1. Possession of a private key, ideally stored on a piece of secure hardware

  2. A biometric or PIN the authenticator uses to locally verify the user’s identity

The specific bits of the messages that state that the authenticator performed User Verification aren’t important for this conversation. What is important is that the website can trust that the user was locally verified before authenticating them. Due to the UV flag being signed over in the message, it is straightforward for the website to trust that the authenticator says that user verification was performed. What’s harder is to ensure that the authenticator isn’t capable of lying about having performed user authentication.

The WebAuthn protocol is community-developed and publicly shared, which means that anyone can implement a CTAP2-compliant authenticator in software at any time, with relatively little effort. There is no inherent requirement in the WebAuthn protocol that authenticators must identify themselves.

In fact the WebAuthn protocol goes to great lengths to ensure that websites cannot use authenticators to de-anonymize users on the Internet, unless they are specifically attempting to identify themselves by logging in. However, what the WebAuthn protocol does provide is a mechanism by which websites can refuse to allow an authenticator to be used unless it strongly identifies itself. Note that we’re not talking about the user’s identity, but the authenticator device’s identity.

The process of determining the provenance of the authenticator is called attestation and it occurs at the same time as user registration. The same way that modern websites may need a certificate issued by a certificate authority in order for browsers to trust them, so too does the authenticator need a certificate issued by a certificate authority for the website to trust it. The certificate authority for authenticators is often simply the manufacturer or vendor that produces the authenticator.

The attestation process works as follows:

  1. When the authenticator is manufactured or produced, the manufacturer issues it a certificate signed by the manufacturer’s certificate authority. The manufacturer’s certificate authority public key is published so it can be used by the website later to verify the legitimacy of the authenticator’s certificate.

  2. When the authenticator generates a new credential for the user during registration, it signs the registration message it sends to the website using its certificate. The registration message is called an attestation object and the signature and public part of the certificate is known as the attestation statement.

  3. During registration, the website receives the attestation object and examines the attestation statement in it. It verifies that the registration message is signed using the private key associated with the certificate the authenticator presented. It then also verifies that the certificate the authenticator presented is properly signed by the manufacturer’s certificate authority.

  4. If the certificates are all signed properly and the verification procedure succeeds, then the website can be assured that the authenticator must have been issued by the manufacturer that published the certificate authority in Step 1. If the website trusts that manufacturer, then it can trust the authenticator to behave according to its manufactured specifications, which may include only setting the UV flag to true if a particular user verification procedure is performed. The details of which manufacturers or even which device models a given website trusts are left up to that website to determine for itself.

This attestation process gives websites a powerful tool to ensure only approved authenticator devices can be used to identify users, but is attestation necessary to realize the security benefits of passwordless? 

The answer is mixed. In high-consequence environments, requiring attestation may be prudent. Ensuring that only authenticators with hardware-backed secure storage or a specific local user verification method can be used could be a necessary precaution to address known threats or conform to regulations. But in many cases, the website operator may not need to have such stringent oversight.

Each user gets to decide which authenticator(s) they use to register a credential to their user account. And with strong authenticators like Touch ID and Windows Hello now regularly present on the same device from which users are accessing their accounts, it may be entirely acceptable not to require attestation and simply trust users to safely store their own credentials. That’s what we do, for the most part, with passwords today. But with WebAuthn credentials, even the most simplistic authenticator, without any secure key storage properties, still needs to be attacked on a local, per-user basis.

Duo’s Passwordless Authentication Resources

 

Try Duo for Free

Want to test it out before you buy? Try Duo for free using our 30-day trial and get used to being secure from anywhere at any time.