Two factor authentication using passkeys

The problems with passwords are so widely understood that pretty much every website now uses some form of secondary authentication. Passkeys negate the need for these secondary factors, offering native support for multi factor authentication.

Primary authentication

Passkeys use public/private keypairs. The private key is stored on the user’s device (or synced to a cloud account). Unlike the shared secret password model, the private key is never transmitted to to website requiring authentication, only the public key is shared during the initial passkey registration.

Something you have

Like TOTP based authenticators e.g. Google Authenticator, Passkey credentials, specifically the private key element are stored on physical devices. The device could be a USB key e.g. a YubiKey or a platform authenticator i.e. smartphone, tablet or computer.

Note: private keys could be synced to a cloud account, however access to the account is itself typically protected by multi-factor authentication.

Secondary authentication

Secondary authentication (aka user verification) guards access to the private keys.

Something you are

Passkeys stored on a compatible device can be protected by biometrics. This will typically take the form of facial or fingerprint recognition e.g. FaceID or TouchID on iOS.

Something you know (fallback)

For devices that lack biometric capaibilities, the authenticator can resort to using a PIN or password to guard access to the private key.

Falling back to a PIN or password may be required even on devices with biometrics if the capability is temporarily unavailable. One scenario in which this could occur would be a laptop with a fingerprint sensor that’s being used in clamshell mode.

Tunable authentication levels

Passkeys enable developers to specify the level of authentication required. Additional secondary authentication is known as user verification. Developers can specify a level of:

• Required - Enforce biometric or passcode authentication or throw an error
• Desirable - Require biometric or passcode authentication if the capability exists
• None

Ultimately it’s up to the browser/authenticator to decide exactly how to enforce these conditions. For example, a TouchID enabled Macbook in clamshell mode would require the user’s password if user verification is set to required but would skip user verification if set to desirable.

Step up authentication

Inevitably there’s a tradeoff between friction/usability and security. Fortunately user verification can be specified on a case by case basis. Logging into a user’s “home page” may require no verification, but accessing the billing data could require verification.