Prevent “Pass the Passkey” Account Takeovers — Harden Your WebAuthn/FIDO Implementations

What Happened

Unit 42 disclosed a class of account takeover issues called “Pass the Passkey” that arise when relying parties fail to validate the WebAuthn/FIDO “User Verified” (UV) indicator on authentication assertions. When servers ignore the UV flag, passkey authentication can be reduced to a possession-only factor: attackers who obtain or replay credentials (for example via credential export, sync, or stolen authenticators) may bypass biometric or PIN verification and complete authentication without the user’s verification step [1].

Why It Matters to Businesses

• MFA undermined: Systems that rely on passkeys to provide multi-factor or high-assurance authentication can be reduced to single-factor possession-only, increasing account compromise risk and exposure to fraud [1].
• Scale of impact: Cloud-synced or roaming authenticators expand the attacker surface — a single leaked or exported credential can enable broad account takeover across devices and services [1].
• Compliance and trust: Regulatory and contractual requirements that depend on strong authentication (financial services, healthcare, enterprise SSO) can be violated if UV is not enforced, risking fines and customer churn.
• Detection blind spots: Many relying parties lack telemetry to distinguish authenticator transports or to policy‑enforce UV and attestation, making detection and incident response slower and less effective [1].

Kimbodo Engineering Perspective

From building production-grade authentication and security systems, the core trade-offs are between user experience (seamless cross-device sign-in) and maintaining cryptographic assurance that the user actually verified the authentication action. Ignoring UV is a dangerous short-term UX optimization that shifts risk to the business.

Practical judgments

• Always treat UV as a security-relevant signal. If a flow requires user verification (biometric/PIN), the relying party must validate the UV flag server-side.
• Differentiate flows by risk profile: low‑risk read-only operations can allow relaxed checks; high‑risk actions (fund transfers, admin access, credential changes) should require UV and stronger attestation.
• Require device binding or attestation for privileged roles and for account recovery paths to prevent abuse via exported or synced credentials.
• Balance blocking vs step-up: where blocking branded users causes unacceptable friction, perform step-up authentication (challenge with an MFA prompt, out-of-band verification, or require a transaction PIN) rather than accepting assertions that have not proven UV.

How We Would Implement It

Immediate steps (audit and harden)

• Audit your WebAuthn server implementation to verify you parse and enforce the authenticator data flags and explicitly check the UV indicator on assertions for flows that require user verification [1].
• Instrument authentication logs to capture: authenticatorTransport, attestation type, credential ID, signCount, UV/UP flags, and originating IP/device fingerprint for post‑incident analysis.
• Add automated tests that simulate assertions with and without UV set to ensure server-side enforcement remains effective across deployment changes.

Policy and architecture changes

• Define a risk-tiered authentication policy:
  • High-risk operations: require UV + attestation (or device binding) and reject assertions that do not prove user verification.
  • Medium-risk operations: allow step-up to UV or alternative MFA when UV is absent.
  • Low-risk operations: allow possession-only flows but monitor and limit sensitive changes.
• Require attestation for initial registration of high-privilege accounts and for recovery/credential reset paths; use attestation metadata and device binding to detect exported or cloned credentials.
• Block or step-up when authenticator transports indicate cloud-synced/platform authenticators for sensitive transactions, or at least apply stricter telemetry and limits to such sessions [1].
• Integrate with risk engines: correlate UV absence, authenticator transport, geolocation, and device posture to trigger adaptive responses (step-up, rate limits, temporary holds).

Operational controls

• Telemetry: log and alert on anomalies such as sudden increases in assertions without UV, credential usage from new transports, or rapid multi-account credential re-use.
• Incident response: have a playbook to rotate credentials, require re-registration of authenticators, and notify affected users when sync/export vectors are suspected.
• User education and support: communicate why re-registration or additional steps are required for high-risk changes and provide clear remediation paths.

Risks, Costs and Security

• Implementation cost: Engineering effort to audit WebAuthn flows, add server-side checks, build risk engines, and deploy tests. Operational cost for telemetry, alerts, and support increases.
• User friction: Enforcing UV and attestation for sensitive flows can break seamless cross-device experiences; expect an increase in support tickets and re-registration requests.
• Compatibility: Some legitimate authenticators or legacy clients may not provide attestations or may expose transports indistinguishably; policies must include measured fallbacks and migration plans.
• Residual threats: Even with UV enforcement, stolen platform authenticators that sync across devices or compromised attestation metadata can enable abuse. UV validation reduces but does not eliminate risk; combine with device binding, anomaly detection, and recovery controls [1].
• Privacy and regulatory: Attestation and increased telemetry must be evaluated against privacy requirements and data minimization principles; store only what is needed for security and incident response.

Bottom line: Treat the WebAuthn UV flag as a security property — validate it server-side, enforce attestation and device binding for sensitive flows, and add risk-based step-up and telemetry. Ignoring UV converts strong passwordless MFA into a possession-only factor and materially increases account takeover risk [1].

Sources

1. [1] Pass the Passkey: A Novel Attack Surface in Passwordless Authentication