Passkey Phishing: Attacking WebAuthn Implementation Flaws

TL;DR

Passkeys (WebAuthn/FIDO2) eliminate password phishing by cryptographically binding authentication to specific domains—fake sites cannot steal credentials. However, passkeys remain vulnerable to implementation flaws in websites, social engineering around account recovery, and device compromise. Organizations adopting passkeys must understand these residual attack vectors and implement defense-in-depth beyond passkey technology alone.

Table of Contents

• How Passkeys Work and Why They Resist Phishing
• Implementation Flaws Developers Introduce
• Social Engineering Around Passkey Recovery
• Device Compromise Attacks
• Passkey Synchronization Security
• Organizational Deployment Risks
• Summary
• Sources
• Important Links

How Passkeys Work and Why They Resist Phishing

Passkeys are a marketing term for WebAuthn/FIDO2 credentials stored in password managers or platform authenticators (Windows Hello, iCloud Keychain, Google Password Manager).

Cryptographic Binding to Origin

Traditional password authentication:

User → Types password into login form
Server → Checks if password matches stored hash

Problem: User can type password anywhere, including phishing sites.

Passkey authentication:

1. Website (example.com) requests authentication
2. Browser verifies origin is example.com
3. Browser retrieves passkey for example.com (domain-bound)
4. Browser generates cryptographic signature using passkey private key
5. Server verifies signature using stored public key

Why phishing fails:

Phishing site (examp1e.com) requests authentication
Browser: "I have no passkey for examp1e.com"
Phishing attempt fails immediately

User cannot accidentally “give away” passkey: The private key never leaves the device. User biometric (fingerprint, face) authorizes signature generation, but biometric data is not sent to server.

What Passkeys Protect Against

Traditional phishing: User enters credentials on fake site → Complete failure against passkeys.

Credential stuffing: Attacker uses breached passwords from other sites → Passkeys don’t use passwords, attack irrelevant.

Keylogging: Malware logs keystrokes → Nothing to log, user presses fingerprint reader instead.

Man-in-the-middle: Attacker intercepts credentials in transit → Credentials are cryptographic signatures, valid only for specific origin, unreplayable.

What Passkeys Don’t Protect Against

Implementation bugs in websites: Developers can implement WebAuthn incorrectly, creating vulnerabilities.

Social engineering of account recovery: Attackers target recovery flows that bypass passkeys.

Device compromise: Malware on device can authorize passkey use if device security is weak.

Insider threats: Admin with database access can potentially link passkeys to real-world identities.

Implementation Flaws Developers Introduce

WebAuthn is cryptographically sound, but incorrect implementation creates attack surface.

Missing Origin Validation

Vulnerability: Server accepts WebAuthn assertions without verifying the origin matches the expected domain.

Example vulnerable code (Node.js):

// INCORRECT IMPLEMENTATION
app.post('/auth/verify', (req, res) => {
  const assertion = req.body.assertion;
  const publicKey = getStoredPublicKey(req.body.userId);
  
  // Verify signature
  if (verifySignature(assertion, publicKey)) {
    // ❌ MISSING: Check assertion.response.clientDataJSON.origin
    res.json({ success: true, token: generateToken(req.body.userId) });
  }
});

Exploitation:

1. Attacker hosts phishing site with subdomain: login.example.com.attacker.com
2. User attempts to authenticate on phishing site
3. Browser generates valid passkey signature for login.example.com.attacker.com
4. Vulnerable server accepts signature without origin check
5. User authenticated to attacker’s session

Fix:

// CORRECT IMPLEMENTATION
const clientData = JSON.parse(base64decode(assertion.response.clientDataJSON));
if (clientData.origin !== 'https://example.com') {
  return res.status(403).json({ error: 'Origin mismatch' });
}

Relying Party ID Confusion

Vulnerability: Website specifies overly broad Relying Party ID, allowing subdomain attacks.

Example:

// Register passkey with RP ID = "example.com"
navigator.credentials.create({
  publicKey: {
    rp: { name: "Example Corp", id: "example.com" },
    // ...
  }
});

Problem: Passkey is valid for:

• https://example.com
• https://login.example.com
• https://subdomain.example.com
• https://attacker-controlled-subdomain.example.com

If attacker compromises any subdomain (via XSS, DNS hijacking, wildcard certificate issuance), they can request passkey authentication.

Best practice: Use most specific RP ID possible. For login.example.com, use RP ID = login.example.com, not example.com.

User Verification Bypass

WebAuthn supports two modes:

User verification required:

• User must prove presence (biometric, PIN)
• High security

User verification not required:

• User only needs to possess device
• Lower security (equivalent to security key tap)

Vulnerability: Developer forgets to require user verification:

// INCORRECT
navigator.credentials.get({
  publicKey: {
    challenge: challengeBytes,
    // ❌ MISSING: userVerification: "required"
  }
});

Result: Passkey authentication succeeds without biometric. If attacker steals unlocked device, they can authenticate without knowing victim’s PIN/biometric.

Challenge Reuse

WebAuthn requires unique challenge per authentication:

Server → Generates random 32-byte challenge
Client → Signs challenge with passkey
Server → Verifies signature and checks challenge wasn't used before

Vulnerability: Server doesn’t track used challenges.

Exploitation:

1. Attacker captures legitimate authentication (man-in-the-middle on network)
2. Replays captured signature to server
3. If server accepts same challenge twice, authentication succeeds

Fix: Store challenges in Redis/database with 5-minute TTL, reject reused challenges.

Social Engineering Around Passkey Recovery

Passkeys eliminate phishing of authentication credentials, but attackers pivot to social engineering account recovery processes.

Account Recovery Fallbacks

Common recovery options:

Option A: Recovery passkey

• User registers backup passkey on separate device
• Attacker cannot easily compromise

Option B: Email-based recovery

• “Can’t sign in? We’ll send a link to your email”
• If email account uses weak authentication, attacker compromises email, then main account

Option C: SMS recovery

• “Verify ownership by entering code sent to your phone”
• Vulnerable to SIM swapping (see previous article)

Option D: Security questions

• “What was your first pet’s name?”
• Vulnerable to OSINT and social engineering

Option E: Support ticket recovery

• User contacts support, proves identity
• Vulnerable to social engineering of support agents

Attack Scenario: Email Recovery Bypass

Target: High-value account protected with passkey (Coinbase, corporate SSO)

Attack flow:

1. Attacker compromises victim's email account (separate attack)
2. Attacker goes to target service, clicks "Can't sign in?"
3. Service sends recovery link to victim's email
4. Attacker accesses email, clicks recovery link
5. Service allows attacker to add new passkey
6. Attacker now has access, victim's original passkey still works (no alert)

Why passkey didn’t help: Recovery flow bypassed passkey authentication entirely.

Support Social Engineering

Attack: Impersonate account owner to support team

Example:

Attacker: "I lost my phone with my passkey and I need to access my account urgently."
Support: "Can you verify your identity?"
Attacker: [Provides stolen PII - name, DOB, last 4 SSN, recent transaction]
Support: "Verified. I'll disable your old passkey and send a new registration link."
Attacker: [Registers attacker's device as new passkey]

Real-world case (2024): GitHub support social engineering incident. Attacker convinced support agent to disable 2FA on target account by providing sufficient identifying information. Account protected with passkey was compromised through support channel.

Device Compromise Attacks

Passkey private keys are protected by device secure enclaves (TPM, Secure Enclave, Titan M), but device-level compromise can still enable attacks.

Malware Authorization Spoofing

Attack: Malware on device intercepts biometric authorization prompts.

Scenario:

1. User browses banking website
2. Malware detects authentication request
3. Malware displays fake biometric prompt: "Verify identity to continue"
4. User provides fingerprint (thinking it's for banking)
5. Malware uses fingerprint to authorize passkey signature for malicious transaction

Platform mitigations:

• iOS/Android: Biometric prompts show app name and cannot be spoofed by other apps
• Windows Hello: Biometric UI is rendered by secure system process
• macOS: Touch ID prompt includes origin domain

Limitation: Effective against most malware, but zero-day OS vulnerabilities could bypass.

Session Hijacking Post-Authentication

Attack: Malware steals session token after passkey authentication succeeds.

Flow:

1. User authenticates to website using passkey (legitimate)
2. Server issues session cookie
3. Malware on device steals cookie from browser memory
4. Attacker uses stolen cookie to access account

Passkey did its job (authenticated user), but post-authentication session is vulnerable.

Mitigation: Short-lived sessions, re-authentication for sensitive actions, device fingerprinting.

Biometric Spoofing

Fingerprint spoofing:

• Create mold of victim’s fingerprint (from glass, photo)
• 3D-print or cast fake fingerprint
• Apply to scanner

Success rate: Varies by scanner quality. High-end smartphone sensors: 5-10% success rate with sophisticated fake. Cheap fingerprint scanners: 50%+ success rate.

Face recognition spoofing:

• 3D-printed face model
• High-resolution photo on tablet
• Deepfake video

Success rate: Depends on liveness detection. iPhone Face ID: Very low (<1% with current techniques). Android face unlock: Variable (10-40% on budget devices).

Physical Device Theft

If attacker steals unlocked device:

• Passkey authentication may succeed without additional biometric (depending on implementation)
• If “user verification not required,” device possession is sufficient

If attacker steals locked device:

• Must bypass device lock (PIN, pattern, biometric)
• Device secure enclave prevents key extraction even with physical access
• Exception: Nation-state actors with specialized hardware (Cellebrite, GrayKey) may extract keys from certain devices

Passkey Synchronization Security

Modern passkey implementations sync across devices via cloud (iCloud Keychain, Google Password Manager). This introduces attack surface.

Cloud Account Compromise

iCloud Keychain:

• Passkeys sync via iCloud
• If attacker compromises Apple ID, they gain access to all passkeys

Google Password Manager:

• Passkeys sync via Google account
• If attacker compromises Google account, they gain access to all passkeys

Attack vector: Traditional phishing or password reuse leads to cloud account compromise, which then grants access to passkeys.

Defense: Strong authentication for cloud accounts (ironically, using passkey for Apple ID / Google account).

Backup and Recovery Keys

Apple iCloud Keychain:

• Passkeys backed up with iCloud backup
• iCloud backup encrypted with account password (not end-to-end encrypted by default)
• Apple can theoretically decrypt (with legal warrant)

Google Password Manager:

• Passkeys encrypted with Google account credentials
• Google has decryption capability

Privacy concern: Nation-state actors with legal access to cloud providers can potentially obtain passkeys.

Comparison: Hardware security keys (YubiKey) don’t sync—keys stay on physical device. More secure but less convenient.

Malicious Sync Device

Attack scenario:

1. Attacker compromises victim's iCloud/Google account
2. Attacker adds attacker's device to account
3. Passkeys sync to attacker's device
4. Attacker can now authenticate as victim on any service

Mitigation: Cloud services send notification when new device is added. User must detect and respond quickly.

Organizational Deployment Risks

Enterprises deploying passkeys for workforce authentication face additional challenges.

Credential Management Complexity

Problem: Employees may register passkeys on personal devices, which organization cannot control.

Scenarios:

• Employee leaves company, passkey on personal phone still works
• Employee device stolen, passkey still valid
• No centralized revocation mechanism

Solution: Use enterprise passkey providers (Windows Hello for Business, Yubico Enterprise, HYPR) with centralized management.

Device Loss and Employee Churn

Problem: User loses device with only passkey registered.

Bad solution: Allow SMS/email recovery (reintroduces phishing risk)

Better solution:

• Require 2+ passkeys at enrollment (primary device + backup security key)
• IT help desk can verify identity in person and re-provision
• Recovery requires manager approval

Phishing Simulation Challenges

Problem: Security awareness training relies on phishing simulations. If passkeys prevent phishing, how do you test user awareness?

Answer: Focus simulations on:

• Social engineering of recovery flows
• Vishing (voice phishing) for support impersonation
• Physical security (device theft, shoulder surfing)
• Insider threat scenarios

Summary

Passkeys provide strong phishing resistance but don’t eliminate all authentication security concerns—organizations must understand residual attack vectors and implement compensating controls.

Key Takeaways:

• Passkeys cryptographically bind authentication to domains, preventing credential phishing
• Implementation flaws (missing origin validation, challenge reuse, weak user verification) introduce vulnerabilities
• Social engineering pivots to account recovery flows that bypass passkeys
• Device compromise allows malware to abuse legitimate passkey authorization
• Cloud sync introduces risk if cloud account credentials are weak

Defensive Strategy:

• Layer 1: Implement WebAuthn correctly (origin validation, RP ID scoping, challenge nonce tracking)
• Layer 2: Secure account recovery (no SMS fallback, require backup passkey or in-person verification)
• Layer 3: Device security (EDR on endpoints, full-disk encryption, remote wipe capability)
• Layer 4: Cloud account protection (passkey for Apple ID/Google account, not password)
• Layer 5: Employee training on non-phishing attack vectors

When to Worry:

• WebAuthn implementation doesn’t validate origin or RP ID
• Account recovery allows SMS or email bypass without passkey
• Employees register passkeys on personal devices without backup
• Cloud account (iCloud, Google) uses weak password instead of passkey
• No EDR monitoring device security

When You’re Protected:

• WebAuthn implementation audited for origin validation, RP ID scoping
• Recovery requires backup passkey or in-person IT verification
• Enterprise passkey management (Windows Hello for Business, Yubico)
• Cloud accounts protected with passkeys themselves (recursive security)
• EDR monitors device for malware attempting passkey abuse
• Employees trained on recovery social engineering risks

Passkey Maturity Model:

Passkeys are the strongest widely-deployable authentication technology, but they’re not a silver bullet. Defense-in-depth remains essential.

Sources

1. FIDO Alliance - WebAuthn Specification

2. W3C - Web Authentication: An API for accessing Public Key Credentials

3. Google - Passkey Implementation Best Practices

4. Apple - Supporting Passkeys

5. Microsoft - WebAuthn Implementation Guide

6. OWASP - WebAuthn Security Considerations

7. Black Hat USA 2023 - Passkey Phishing Research

8. GitHub Security - Account Recovery Social Engineering Incident (2024)

9. Yubico - Enterprise Passkey Management White Paper

10. Duo Security - Passkey Adoption Report 2025

11. NIST SP 800-63B - Authenticator Assurance Levels (Including Passkeys)

12. Cloudflare - Passkey Implementation Case Study

Important Links

1. Passkeys.dev - Comprehensive passkey implementation guide

2. WebAuthn.io - Test WebAuthn registration and authentication

3. FIDO Alliance - Passkey standards organization

4. YubiKey - Hardware passkey (FIDO2 security key)

5. Windows Hello for Business - Enterprise passkey management

6. 1Password Passkey Support - Passkey manager integration

7. Bitwarden Passkey Support - Open-source passkey management

8. SimpleWebAuthn Library - WebAuthn implementation for Node.js

9. Passkey Ready - List of sites supporting passkeys

10. HYPR Passwordless MFA - Enterprise passkey platform