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

MFA & Biometrics

WebAuthn extensions in production: largeBlob, credProtect, devicePubKey. FIDO MDS attestation chains. Hybrid transport for cross-device auth.

You will learn

  • The largeBlob extension and what authenticators can store on it
  • credProtect levels and the privacy/security trade-offs
  • devicePubKey for device-bound keys synced across user devices
  • How FIDO Metadata Service validates attestation chains
  • Hybrid transport (caBLE/CTAP 2.2) for phone-as-authenticator on a desktop

largeBlob

WebAuthn extension that lets a relying party store opaque per-credential data on the authenticator. The blob is cryptographically bound to the credential and encrypted by the authenticator. Use cases:

  • Encrypted symmetric keys for client-side encryption ("the key is wrapped on the security key").
  • Recovery tokens that survive device loss because the authenticator carries them.
  • Per-credential metadata that the server prefers not to track centrally.

Authenticator support is partial; check authenticator capabilities at registration.

credProtect

Three levels controlling whether a credential is even visible to a relying party that does not know its credential ID:

  • userVerificationOptional: default. Credential is enumerable.
  • userVerificationOptionalWithCredentialIDList: only returned when the RP supplies a credentialID in the allow-list. Prevents enumeration.
  • userVerificationRequired: also requires user verification (PIN, biometric) on every assertion.

Higher levels hide which sites a user has accounts on. Important for privacy-sensitive accounts (whistleblowing platforms, dating apps).

devicePubKey

For synced passkeys, the relying party may receive a different "device public key" for each device the credential is unlocked on, even though the underlying credential is the same synced passkey. This lets the RP:

  • Detect that a sign-in is coming from a newly-syncing device (challenge step up).
  • Audit which device performed which action.
  • Make per-device revocation possible without revoking the credential everywhere.

devicePubKey is opt-in per RP and per assertion.

FIDO MDS

The FIDO Metadata Service publishes signed metadata for every FIDO-certified authenticator: AAGUID (Authenticator Attestation GUID), supported algorithms, certification level, known firmware vulnerabilities. Relying parties that want to enforce "only certified hardware keys for admins" download the MDS daily and validate attestations against it.

Without MDS validation, an attestation is just a signature; the RP cannot easily decide whether the device is a YubiKey or an unknown vendor's authenticator that may have weaker certification.

Hybrid transport (caBLE / CTAP 2.2)

The Cloud-assisted Bluetooth Low Energy protocol lets a user sign into a desktop browser using a phone's passkey:

  1. Browser displays a QR code containing a session token.
  2. Phone scans the QR. Phone and browser bootstrap a BLE channel using the session token.
  3. Phone proves proximity (BLE RSSI / advertising) and performs the WebAuthn assertion.
  4. Browser receives the signed assertion via the BLE channel.

Phishing-resistant because the assertion includes the actual origin from the browser. Proximity-required because BLE drops out beyond a few meters. The user experience finally usable in 2024; widely supported across iOS/Android/Chrome/Safari.

Attestation in practice

Enterprises usually allow "self attestation" (no formal attestation) for consumer accounts and "direct attestation" with MDS validation for privileged users. Three deployment patterns:

  • Tiered policy: regular users may use any authenticator; admins must register a YubiKey 5 or equivalent.
  • Attestation pinning: lock an admin's account to a specific AAGUID after first registration, refusing new device types.
  • Audit-only: collect attestation for telemetry but do not gate. Useful for understanding the fleet before enforcing.
Take the quizBack to intermediate