auditing-webauthn-and-passkey-flows

name	auditing-webauthn-and-passkey-flows
description	Audit the server side of passwordless authentication for ceremony-verification bugs that let an attacker-shaped response become an authenticated session. Covers a registration or authentication ceremony whose challenge is not bound to a server-issued single-use value, an origin or relying-party identifier that is never checked or checked by substring, a user-verification flag ignored when policy required it, attestation accepted when it was required, a signature counter regression that hides a cloned authenticator, and the highest-severity case where a cryptographically valid assertion seats a session for a user other than the one the credential is bound to. Use when reviewing code that verifies a registration or authentication ceremony and establishes identity from the result. The attacker-shaped ceremony response is the source, the authenticated session is the sink, and a missing required check between them is the bug.
license	MIT

Auditing passkey and WebAuthn ceremonies: when a verified signature seats the wrong user

A passkey ceremony proves that some authenticator signed a challenge. It does not, by itself, prove who is signing in. Every WebAuthn bug worth finding lives in the gap between "this signature is valid" and "therefore user U is logged in," and that gap is closed only by a specific list of server-side checks. When one of those checks is missing, homegrown, or bypassable, attacker-shaped bytes from the ceremony response flow straight into an authenticated session. You find these by reading the verification path and asking, for each required check, whether it runs and whether the value it checks is the one the attacker cannot forge.

When to use

• Code verifies a WebAuthn registration or authentication response and then creates a credential or a session.
• The application implements the ceremony itself, or calls a library but supplies the policy and expected values.
• You want to know whether a valid signature can be replayed, phished, or bound to the wrong account.

Scope check

Test passkey flows only on systems you own or are authorized to assess, with test accounts and test authenticators. A ceremony bypass is an authentication bypass, so treat any confirmed finding as account-takeover-grade and coordinate disclosure. If you can't name the authorization, stop.

The loop

1. Map the verification path and whether a library owns the ceremony. Find the registration and authentication endpoints and the function that decides success. Determine whether the ceremony is delegated to a conformant verification library or hand-rolled. If a library owns it, the bug moves from "missing check" to "wrong arguments": read what expected-challenge, expected-origin, expected relying-party identifier, and required-user-verification values are passed in. A library called with defaults verifies only what you gave it.

2. Check challenge binding. The challenge in the response must equal a value the server generated, stored against this session, has not used before, and has not let expire. The bug is a challenge compared against a client-sent field, against a constant, or not at all, or a challenge that is never invalidated after use so the same response replays. If nothing reads a server-side challenge store before the compare, the ceremony is replayable.

3. Check origin and relying-party identifier. The response carries the origin the ceremony ran on and a hash of the relying-party identifier; both must match an exact allowlist. A substring, suffix, or pattern match is the classic bug: a suffix test for one domain also accepts a lookalike that ends with it. Missing origin checks turn a phishing relay into a working login.

4. Check the user-verification flag and attestation when required. If policy asked for user verification, the code must read the user-verified bit, not just user-presence; ignoring it silently downgrades two factors to one. If policy required attestation, the attestation statement and its trust path must actually be verified; "required in config, accepted unchecked in code" is the bug. A ceremony that legitimately requires neither is a design choice, not a finding.

5. Check credential-to-user binding and the signature counter. This is the highest-severity step. The credential must be looked up by its identifier and confirmed to belong to the user being seated, or the seated user must be derived from the credential's bound handle, never from a separate client-controlled field. A valid signature over credential A that logs you in as user B is a total authentication bypass. Then, if the stored counter is non-zero, a new count that is not strictly greater signals a cloned authenticator and must be rejected; a zero counter is spec-permitted and is not a regression.

6. Confirm and record. Confirm by exercising the live verification path with a test authenticator and a modified response that removes or alters the value under test, showing the ceremony still succeeds. Kill the lead if a conformant library performs the ceremony and is called with a server-stored single-use challenge, an exact expected origin and relying-party identifier, the required user-verification policy, and the session is seated strictly from the credential-bound user. Record the endpoint, the missing or bypassable check, and the seated identity.

Where passkey trust leaks

• The credential proves possession, not identity. The server, not the signature, decides which account the possession maps to. Bind the session to the credential's user or nowhere.
• The challenge is the only thing that makes a replay fail. If it is not server-issued, single-use, and bound to the session, a captured response works twice.
• Origin is the phishing boundary. An exact-match origin check is what stops a relayed ceremony; a suffix or contains check quietly reopens it.
• The user-verification flag is the second factor. Passwordless is only multi-factor if the code actually reads that bit; unread, it is single-factor with extra steps.
• A library hides the bug in its arguments. A conformant verifier called without the expected challenge, origin, or relying-party identifier checks nothing you did not hand it.

Worked example (a confirm and a kill)

Confirm. The authentication endpoint verifies the assertion signature against the stored public key and returns success, then seats the session from a userId field in the same request body. A test authenticator's own valid assertion, submitted with a victim's userId, logs in as the victim. The credential was never checked to belong to the seated user. Confirmed credential-to-user binding confusion, critical, remediation = derive the session identity from the user bound to the matched credential handle and never from a client-supplied field.

Kill. The same endpoint passes the response to a conformant verification library with the server-stored single-use challenge, an exact expected origin, the expected relying-party identifier, and a user-verification-required policy, then seats the session only from the credential record's owner on success. Altering the origin or reusing a challenge makes the library reject the ceremony. Killed, kill_reason = "ceremony delegated to a conformant verifier with server-stored single-use challenge, exact origin and relying-party checks, required user verification, and identity seated from the bound credential; tampered responses are rejected."

Rationalizations to reject

• "The signature verified, so the user is authenticated." -> Verified against which credential, and is that credential bound to the user you are about to seat? A valid signature for the wrong account is a bypass.
• "We check the origin." -> Exact match or substring? A suffix test for your domain also accepts a lookalike that ends with it. Only an exact allowlist is a check.
• "It is passwordless, so it is strong." -> Only if the code reads the user-verified bit. Unread, a passkey is a single factor no matter how it was provisioned.
• "A counter of zero means our check is broken." -> Zero is permitted by the spec; the regression is a decrease from a non-zero stored value, not the presence of a zero.
• "The library handles all of this." -> Only for the values you pass it. A verifier called with defaults and no expected origin or challenge verifies a signature and nothing else.

Executing this in practice

You need the bodies of the registration and authentication verification functions, the policy object that declares user-verification and attestation requirements, the code that stores and looks up challenges, the credential-store lookup, and the exact line where the session user is set. For each required check, decide whether it runs on the live path and whether the value it tests is attacker-forgeable. Reading the verification function and its callees tells you which checks exist; replaying a tampered response against a test account tells you which ones actually hold.

Related

• auditing-saml-and-oidc-flows - the federation sibling; both hunt an authentication ceremony that establishes identity from attacker-reachable input, and both fail when a binding check is skipped.
• auditing-device-code-and-pkce-flows - another authentication-flow audit where the bug is a proof that binds a request to its initiator being unenforced.
• auditing-randomness-and-nonce-quality - a predictable challenge is a passkey bug rooted in weak randomness; that skill covers the entropy of the values this one assumes are unguessable.
• FINDING-SCHEMA.md - source = the attacker-shaped ceremony response, sink = the authenticated session, evidence = the tampered response that still succeeds and the seated identity.