Chapter 3 · Authentication & Access· Intermediate· ~16 min

MFA & Biometrics

WebAuthn under the hood: what the browser actually signs, how attestation works, and the trade-offs between hardware keys, platform passkeys, and synced passkeys.

You will learn

  • What WebAuthn ceremonies (registration, authentication) actually exchange
  • How origin binding makes WebAuthn phishing-resistant
  • What attestation tells the server about the authenticator
  • Hardware key vs platform passkey vs synced passkey: when each fits
  • Why TOTP still has a place even after passkeys

The two WebAuthn ceremonies

WebAuthn has two flows. Registration creates a new credential bound to (user account, relying-party origin). Authentication proves the user holds the private half of an existing credential.

Both follow the same shape:

  1. Server creates a fresh random challenge (at least 16 bytes).
  2. Server sends the challenge to the browser along with the relying-party ID (the origin's effective domain) and the user identity.
  3. Browser asks the authenticator to sign a structured value that includes the challenge, the origin, and a few metadata fields.
  4. User presents the authenticator (touch, biometric, PIN). The authenticator returns a signature.
  5. Browser forwards the signature to the server. Server verifies the signature, the origin, the challenge, and the counter.

Origin binding: why phishing fails

The structured value the authenticator signs includes the origin exactly as the browser observed it. A phishing site at app.example.evil.com presenting a copied page can ask for a WebAuthn assertion, but the authenticator will sign app.example.evil.com, not the real app.example.com. The server's verification will fail because the signed origin does not match the one it expects.

This is the whole game. No phishing page, however convincing, can produce a signature for the real origin. The credential is mathematically bound to the URL bar.

Attestation: optional, often skipped

At registration, the authenticator can include an attestation: a cryptographic claim about its make, model, and origin. The server can use it to enforce policy like "only allow FIDO-certified hardware keys" for high-security users.

Three modes:

  • None: most common for consumer sites. The server does not care which authenticator.
  • Indirect: anonymized attestation, useful for telemetry without identifying individual devices.
  • Direct: full attestation. Required for enterprise policies that want only specific vendors.

Note that attestation has privacy implications. Major browsers warn the user before sending direct attestation to a site that did not previously know which device they use.

Hardware key vs platform vs synced

  • Roaming hardware key (YubiKey, Titan): private key never leaves the device. Best for security-critical accounts and admins. Lose the key, lose access unless you registered a backup.
  • Platform authenticator (Windows Hello, macOS Touch ID, Android biometric): bound to the device. Convenient. Lose the device, lose access on that device.
  • Synced passkey (iCloud Keychain, Google Password Manager, 1Password): the credential syncs across the user's devices via the password manager's E2EE storage. Resilient to device loss; trust shifts to the password manager's account security.

Best practice for important accounts: at least one hardware key + a recovery option (a second hardware key, or a synced passkey on a well-protected password manager). Single-device passkeys without backup are an outage waiting to happen.

Synced passkeys shift the trust

A synced passkey is only as strong as the account that syncs it. If your Apple ID or Google account uses SMS recovery, an attacker can take over your sync and import every passkey. Make sure the syncing account itself uses phishing-resistant MFA.

Where TOTP still fits

WebAuthn is strictly better than TOTP for phishing resistance, but TOTP is not dead:

  • Devices that cannot do WebAuthn (legacy operating systems, kiosks, terminals).
  • Services that have not yet shipped WebAuthn support.
  • Recovery: TOTP through a different app on a different device is often the offline backup that lets you survive losing your hardware key.

Modern stack for a security-conscious user: one or two hardware keys for primary, a synced passkey on a hardened password-manager account as backup, TOTP only where WebAuthn is not available, SMS never if you can help it.

CTAP2: how the browser talks to the key

WebAuthn is the JavaScript API the browser exposes. CTAP2 is the wire protocol between the browser and the external authenticator, over USB, NFC, or Bluetooth. Modern protocols include a PIN protocol for unlock and a hmac-secret extension that lets applications derive secrets from the authenticator without exposing the private key.

Most application developers never touch CTAP2 directly; the browser handles it. Knowing the name helps when you read incident reports about authenticator firmware bugs.

Take the quiz Back to the beginner version