Passkeys

Passkeys are a passwordless authentication credential: a per-service public/private key pair in which the private key stays on the user’s devices and the relying party (RP) stores only the public key. Built on the FIDO2 / WebAuthn standards, they are unlocked locally with biometrics or a PIN, are unique per service by construction, and are phishing-resistant because the browser/OS enforces that a credential is only ever used for the service it was created for — trust no longer depends on a human spotting the right URL.¹

Two storage models matter:

• Device-bound passkeys — the private key never leaves one authenticator (hardware security key, TPM, phone secure enclave). Strongest against export; painful on device loss.
• Synced passkeys — the private key is encrypted and replicated across a user’s devices by a cloud credential manager (Google Password Manager, iCloud Keychain, password managers). Convenient, and the dominant consumer model — but sync machinery becomes part of the attack surface.²

The synced-passkey security model (Google / Chrome on Windows)

Google’s implementation is the instructive reference because of its scale. Private keys are encrypted under a symmetric master key — the security domain secret (SDS, 32 bytes) — and decryption is supposed to happen only inside Google’s cloud authenticator enclave. The client device holds two hardware-backed keys that gate access to that enclave: a device identity key (proves “this is a registered device”) and a user-verification (UV) key (proves “a human unlocked this device with PIN/biometric”). The returned authentication assertion carries a one-bit User Verified (UV) flag recording which key signed the request.³

The model’s three load-bearing assumptions: users explicitly consent (user presence); MFA requires a real device unlock (user verification); and passkey private keys cannot be copied or shared.⁴

Pass-ta-key: the endpoint strikes back (Unit 42, Aug 2026)

In August 2026, Palo Alto Networks’ Unit 42 (Arie Olshtein) disclosed Pass-ta-key, three attack classes against Google Password Manager synced passkeys in Chrome on TPM-equipped Windows devices. None break the cryptography; all assume commodity malware already running as an unprivileged user on the victim endpoint. The name puns on “passkey” and “pass the key” — a deliberate heir to the pass-the-hash family.⁵

Stage zero — recon. Chrome persists synced passkey records as proto-encoded WebauthnCredentialSpecifics in the profile’s sync LevelDB (%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB), readable without elevation. An attacker learns every service where the victim uses passkeys, plus usernames, credential IDs, and the (SDS-encrypted) private keys.⁶

1. Pass-ta-key — device identity impersonation. Chrome stores the TPM-wrapped identity key as wrapped_identity_private_key in the passkey_enclave_state file (exported via NCryptExportKey as an NCRYPT_OPAQUE_KEY_BLOB). Malware re-imports that blob through standard CNG calls (NCryptOpenStorageProvider / NCryptImportKey / NCryptSignHash) — no admin, no unlock prompt — and signs a cloud-authenticator request exactly as Chrome would. The enclave returns a valid assertion… with the UV flag unset. Whether the attack works therefore reduces to one bit and whether the RP checks it: GitHub validated UV and rejected the login; eBay set userVerification=required but never validated the flag, and account takeover succeeded (fixed after disclosure). An RP that skips UV validation silently degrades passkey MFA to single-factor possession of the device.⁷⁸

2. Silver Pass-ta-key — forge the verification key. The attacker deletes passkey_enclave_state (or issues a device/forget), forcing re-onboarding. Chrome registers the device in a uv_key_pending state — the UV key is only created on the second passkey use, to avoid stacking a Windows Hello prompt on the recovery-PIN prompt. In that window the attacker submits their own public key via device/add_uv_key, and the cloud authenticator does not validate attestation of newly registered UV keys. Assertions signed with the attacker’s key carry UV=1 — full account takeover, from the attacker’s own hardware, with no further access to the victim’s device.⁹

3. Golden Pass-ta-key — steal the master key. Every device joining or rejoining the security domain retrieves the SDS from Google’s Trusted Vault — in an accessible client-side form, even though the cloud authenticator could have performed recovery without exposing it (likely to match the iOS/Android model, where the client must hold the key). Unit 42 first found the SDS in plaintext in chrome://device-log FIDO logs (removed after disclosure), but it remains transiently present in Chrome’s process memory during onboarding: force a re-registration, dump memory, recover the 32-byte secret. With the SDS plus the stage-zero sync records, the attacker decrypts all synced passkey private keys — present and future — and can export them for sale or reuse. Critically, Google’s implementation offers no way to rotate or revoke the SDS, so even detected compromises have no clean remediation.¹⁰¹¹

The silver/golden escalation mirrors the [[golden-and-silver-ticket-attacks|Kerberos ticket hierarchy]]: silver forges a usable artifact for ongoing access; golden seizes the master secret itself (krbtgt ≈ SDS) and becomes nearly unremediable without key rotation.

Mitigations

• Relying parties: set userVerification=required and actually validate the UV flag in every assertion — the eBay failure mode.
• Credential managers: verify attestation/origin of newly registered device keys (identity and UV); treat unexpected recovery-PIN prompts during normal use as a signal; never let master key material touch client memory or logs — perform crypto on the client’s behalf inside the enclave.
• Platform hardening: restrict access to the sync database and passkey_enclave_state to the browser process; monitor for deletion/modification of local passkey state followed by re-onboarding.
• Detection gap: WebAuthn’s signCount is constant across synced passkeys by design, so RPs lose the classic cloned-credential signal; coordinated counters remain an open problem.¹²

Assessment

Passkeys still retire entire attack classes (phishing, reuse, breach-of-shared-secrets) — the credential-theft market’s reliable tools. What Pass-ta-key demonstrates is that endpoint compromise never left the threat model: when authentication decisions rely on signals from the user’s device (device keys, UV bits, local state files), malware on that device can manufacture the signals. Hardware backing and cloud enclaves raise the bar but route around the human, not the machine. The durable lessons for practitioners: validate UV server-side, treat re-onboarding/recovery flows as security-critical events, and remember that “the private key can’t be copied” is a property of the implementation’s key handling, not of public-key cryptography.¹³

See also: pass-the-hash (the naming ancestor — reuse without the secret), mimikatz (process-memory credential extraction, the LSASS analog of the Chrome SDS dump), windows-saved-credentials (other Windows credential stores), conference-device-security (endpoint threat models on the road), json-web-tokens (another assertion-validation failure family), kerberos, security-awareness-training (the evidence base for preferring phishing-resistant auth over training the human).

Sources

• 2026 — Pass the Passkey: A Novel Attack Surface in Passwordless Authentication
• 2026
• What are passkeys?

Footnotes

1. What are passkeys? ↩

2. 2026 — Pass the Passkey: A Novel Attack Surface in Passwordless Authentication ↩

3. 2026 — Pass the Passkey: A Novel Attack Surface in Passwordless Authentication ↩

4. 2026 — Pass the Passkey: A Novel Attack Surface in Passwordless Authentication ↩

5. 2026 — Pass the Passkey: A Novel Attack Surface in Passwordless Authentication ↩

6. 2026 — Pass the Passkey: A Novel Attack Surface in Passwordless Authentication ↩

7. 2026 — Pass the Passkey: A Novel Attack Surface in Passwordless Authentication ↩

8. 2026 ↩

9. 2026 — Pass the Passkey: A Novel Attack Surface in Passwordless Authentication ↩

10. 2026 — Pass the Passkey: A Novel Attack Surface in Passwordless Authentication ↩

11. 2026 ↩

12. 2026 — Pass the Passkey: A Novel Attack Surface in Passwordless Authentication ↩

13. 2026 — Pass the Passkey: A Novel Attack Surface in Passwordless Authentication ↩