The hmac-secret-mc extension derives a 32-byte secret during MakeCredential. On firmware 5.8 this completes in a single user interaction. Previous firmware required a separate GetAssertion call with the hmac-secret extension (two interactions).
Before hmac-secret-mc, generating an encryption key from a hardware key meant two user touches: one to register, one to derive the secret via assertion. If your app needs both an authentication credential and an encryption key at signup, that’s two taps back to back with no obvious reason from the user’s perspective.
With hmac-secret-mc the secret comes back in the registration response. One touch, done. This is what makes it practical to do things like:
Client-side encryption at signup. Derive a symmetric key during registration and use it to encrypt data in the browser or app before it ever hits your server.
Per-purpose keys from one credential. Use different salts to derive separate keys for authentication, file encryption, and transaction signing, all from the same credential.
Federated key derivation. A payment provider derives its own key from the merchant’s credential using its own salt, no shared state needed.
The client provides a 32-byte salt.
The salt is attached to the MakeCredential request via the hmac-secret-mc extension.
The authenticator creates the credential, computes HMAC-SHA-256 over the salt using a credential-scoped internal key, and returns the 32-byte result in the registration response.
The client extracts and decrypts the secret from the authenticator data.
The credential’s internal key never leaves the authenticator. The output is encrypted in transit using the ECDH-derived shared secret between client and authenticator.
hmac-secret |
hmac-secret-mc |
|
|---|---|---|
When secret is derived |
During |
During |
User interactions |
Two (register, then assert) |
One (register) |
Firmware required |
5.2 or later |
5.8 or later |
Two 32-byte salts can be provided to receive 64 bytes of output (two independent 32-byte values). This supports key rotation: derive with both old and new salt in a single operation. It’s also useful for standard encrypt-then-MAC designs where you need one key for AES encryption and a separate key for HMAC integrity, without reusing the same key for both.
hmac-secret was introduced in CTAP 2.0 and has long been supported on YubiKeys. hmac-secret-mc requires firmware 5.8+. Check the authenticator’s supported extensions at runtime and fall back to the two-step hmac-secret flow when hmac-secret-mc is not available.
On the browser side, both extensions surface through the WebAuthn PRF extension. The browser handles the negotiation; your RP doesn’t need to know which CTAP extension is being used underneath.