Passkey Interview Questions: WebAuthn, Origin Binding, and Account Recovery

A candidate says, “Passkeys are phishing-proof, so we no longer need an account-recovery threat model.” The interviewer takes away the user's phone and asks how they sign in tomorrow. That follow-up exposes the central trade-off: WebAuthn can bind a credential to a relying party and resist credential replay on a lookalike site, while a weak fallback can still hand an attacker the account. A good answer explains both the cryptographic sign-in and the human recovery path.

This guide uses the W3C Web Authentication specification for browser and relying-party behavior and FIDO Alliance's passkey guidance for deployment terms. It describes a design exercise, not every browser's UI or every provider's account policy.

Interview prompt: a lookalike site and a lost device

Your service uses passkeys for consumer sign-in. A user registered one passkey on a phone. An attacker creates a convincing lookalike domain and asks the user to approve sign-in. Later, the legitimate user loses the phone. Explain what the browser and authenticator do on the lookalike site, what the server verifies on the real site, and how the user can regain access without turning email or support into an easier account-takeover path.

Clarify the assumed account model before proposing a fix. Can the user register multiple passkeys? Is the credential synced through a platform passkey provider or bound to a device? Does the service retain a password fallback, a recovery code, a verified recovery contact, or a managed-device enrollment path? Are high-risk actions such as changing payout details protected by step-up authentication? These choices change the threat model. The word “passkey” alone does not decide them.

Registration: what is stored where?

At registration, the relying party creates a fresh challenge and requests a credential for its relying-party ID (RP ID). The browser invokes an authenticator under WebAuthn's origin and RP ID rules. The authenticator generates a public/private key pair or uses an appropriate credential mechanism; the relying party receives the credential ID and public key, not the private key. A synced passkey may be backed up by a passkey provider; a device-bound credential stays on its device or security key according to its implementation and policy. The server stores the credential ID, public key, account binding, RP ID context, and metadata needed for future verification.

The server must verify the registration result, not assume the browser response is trustworthy because it arrived over HTTPS. Check the returned challenge against a pending, one-time server challenge; verify clientDataJSON.type is the creation operation, validate the origin against the allowed origin set, check the RP ID hash and user-presence/user-verification flags according to policy, and validate attestation if the deployment actually requires it. A consumer site that accepts any authenticator may not need a restrictive attestation policy; a managed enterprise deployment might. State why, rather than treating attestation as a magic security toggle.

Local biometric or device PIN unlock is not the same as sending a fingerprint to the website. The authenticator produces a cryptographic result after user interaction. The relying party sees verification flags and a signature/attestation result, not a reusable biometric template. Nor does a biometric automatically prove the device belongs to the expected human: device sharing, enrollment policy, and recovery remain account-level questions.

Authentication: reconstruct the signed assertion

At sign-in, the server generates a fresh, unpredictable challenge tied to the pending ceremony. The browser requests a credential scoped to the RP ID, and the authenticator returns an assertion. The signed bytes cover authenticator data plus a hash of client data; the client data includes the challenge, origin, and ceremony type. On the server, find the stored public key for the credential ID and verify the signature and the expected fields. The W3C's assertion-verification steps are the canonical reference for precise order and requirements.

Check	What it prevents or establishes	A useful failure test
Fresh challenge and transaction binding	Old assertion is not replayed as a new login	Reuse a challenge or swap between sessions
type and allowed origin	Response belongs to the intended ceremony and site origin	Submit an assertion from an unapproved origin
RP ID hash	Authenticator data is scoped to the expected relying party	Substitute another RP ID
User-presence and user-verification flags	Ceremony met the service's interaction policy	Require UV but receive only UP
Signature against stored public key	A registered credential approved this challenge	Alter signed bytes or use another key
Account and credential status	Credential is active for this account	Try a deleted or suspended credential

An exact list of acceptable origins matters in deployments with several app origins. Do not compare a URL by loose suffix or substring. The RP ID is a domain identifier, while an origin includes scheme and host (and port where applicable); they are related but not interchangeable. WebAuthn permits certain valid subdomain relationships under its rules, so an answer that says they must always be identical is too simple. Define your actual allowed origins and RP ID and test them. Keep the pending challenge short-lived and single-use under your session model.

The signature is essential, but it is not the whole account decision. After verification, enforce credential status, account suspension, risk policy, and authorization for the requested operation. A valid login should not automatically let a newly recovered account change a payment destination. Rate limiting and abuse monitoring still matter for account discovery and recovery flows, even though offline guessing of a passkey private key is not the password threat model.

Why a lookalike origin does not get the same credential

Suppose the legitimate RP ID is shop.example, while the attacker controls sh0p.example with a zero. The lookalike can draw a similar sign-in button but cannot claim the legitimate RP ID under conforming browser/credential scoping. A credential created for shop.example is not offered as a credential for sh0p.example. If the attacker invokes WebAuthn for its own RP ID, it is asking for a different credential, not obtaining a signature from the legitimate one. The real relying party also checks the origin in client data and the RP ID hash in authenticator data before accepting an assertion.

This is a narrower, stronger statement than “phishing is impossible.” Malware on an endpoint, a compromised legitimate origin, a malicious browser or authenticator, session theft after login, or a weak help-desk recovery path are different threats. The W3C specification describes origin validation as an additional layer even though credential scoping already helps. A senior answer names exactly which attacker action WebAuthn blocks and which actions need separate controls.

For a related-origin deployment, ask whether the browser/platform supports the selected RP ID relationship and whether every allowed origin belongs to the service. A broad wildcard that includes user-controlled subdomains undermines the origin boundary. Test the actual hostname and browser behavior in a staging environment. Do not write an assertion-verification routine from scratch for production when a maintained library can implement the ceremony and edge cases; still know the verification contract well enough to configure it correctly.

Synced and device-bound passkeys are not the same recovery story

FIDO Alliance distinguishes passkeys synced through a provider from device-bound passkeys that never leave one device. Both use public-key authentication and RP scoping, but their loss and assurance properties differ. A synced credential may become available on another device after the user recovers access to the provider account. That makes the provider's own account recovery and sync security part of your effective trust chain. A device-bound key can reduce replication but raises the chance that loss requires another registered credential or a deliberate recovery procedure.

Do not claim “synced means insecure” or “device-bound means unrecoverable.” A user might have two device-bound security keys registered. A synced provider may offer strong account protections. Conversely, a service can add a weak password fallback to a device-bound credential and lose much of its phishing resistance. FIDO's synced-passkey deployment guidance treats recovery and assurance as deployment decisions, not a binary label.

Design the lost-device recovery path

The lowest-friction path is another passkey the user registered earlier—perhaps on a second device or a hardware security key. Once authenticated, let the user review registered credentials, revoke the lost device's credential when appropriate, and add a replacement. If a synced passkey becomes available through the provider on a new device, the provider's recovery process may be the actual first step; the relying party must still perform normal WebAuthn verification when that passkey is used.

If no credential is available, use a separately designed account-recovery flow. A recovery code stored offline, a pre-enrolled trusted contact or device, identity proofing for a regulated service, and reviewed support escalation have different costs and assurance. None is automatically safe. Bind recovery requests to the correct account, prevent enumeration, throttle attempts, notify existing channels where possible, delay high-risk changes, and give the legitimate user a way to contest a takeover. Verify the recovery channel itself and record which assurance level it supplies.

Recovery path	Availability benefit	Attack surface to test
Another already registered passkey	Preserves primary cryptographic sign-in	Lost device still has an active credential until removed
Synced passkey on replacement device	Reduces permanent lockout	Passkey-provider account recovery and device trust
One-time recovery code	Works without original authenticator	Code storage, theft, replay, and brute-force controls
Email or help-desk recovery	Broad accessibility	Inbox compromise, social engineering, and weak identity checks

If ordinary email alone can immediately add a new passkey and transfer assets, the attacker may bypass the phishing-resistant sign-in by compromising the mailbox. For a low-risk consumer forum, a service might knowingly accept that trade-off. For a financial account, it may require a cooling-off period, stronger verification, and temporarily restricted actions. State the product's risk tolerance rather than claiming a universally correct recovery policy. FIDO's phishing and account-recovery discussion reinforces that protection depends on the whole account lifecycle.

After recovery, do not assume an old credential can be cryptographically destroyed on a stolen offline device. Remove its server-side credential record so future assertions from that credential ID are rejected, invalidate relevant sessions, review recent actions, and notify the user. If a synced provider has copies, provider-level controls may also be needed. Log recovery events without collecting biometric or private-key material. Include a tested route for mistaken lockout and for support staff abuse.

An interview-ready answer

“Registration binds a public key and credential ID to an account and RP ID after challenge and origin checks; the private key stays under authenticator/provider control. At login, I verify a fresh challenge, ceremony type, allowed origin, RP ID hash, required user flags, signature under the stored public key, and credential/account status. A lookalike origin cannot simply request the legitimate RP credential under conforming WebAuthn behavior, but that does not solve malware, session theft, or recovery fraud. I would encourage a second passkey and design a separately risk-rated lost-device path, with notification, throttling, credential revocation, and delay or review for high-impact changes. The weakest acceptable recovery path sets the account's real assurance.”

That is a stronger answer than “WebAuthn replaces passwords.” It names the concrete bytes and server decisions that make origin binding useful, and it accounts for the day the user's only device disappears. The exact UX, attestation policy, sync model, and fallback must be verified for the product and supported platforms rather than inferred from a browser screenshot.

Sources and Further Reading

• W3C Web Authentication: Level 3 — ceremonies, RP ID/origin rules, and verification steps.
• FIDO Alliance: Passkeys — synced and device-bound terminology.
• FIDO Alliance: Synced Passkey Deployment — recovery and deployment trade-offs.
• FIDO Alliance: Passkeys and Phishing Prevention — account-lifecycle security context.