Passkeys Still Kill Phishing. Malware Is Another Story.

The passkey pitch has always leaned on one word: unphishable. There's no shared secret to lure out of a user, no reusable credential to replay, so the whole category of credential-stuffing and phishing kits is supposed to evaporate. That pitch holds. What Palo Alto Networks' Unit 42 just published is a reminder that "unphishable" and "unstealable" are not the same word, and that the second one was never true for synced passkeys running in a consumer password manager.

The research describes three techniques — Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key — against Google Password Manager passkeys in Chrome on Windows machines with a TPM. If those names sound familiar, they should: they're a direct riff on the Kerberos playbook of pass-the-key, silver ticket, and golden ticket, and the escalation ladder maps almost perfectly. That framing is the most useful thing to take away, so let's use it.

Three rungs, escalating blast radius

The bottom rung, Pass-ta-key, is credential forgery for one login. Chrome keeps a TPM-wrapped device identity key as an NCRYPT_OPAQUE_KEY_BLOB, and here's the sharp edge: because the key is used through Windows CNG (NCryptImportKey, NCryptSignHash) rather than sealed to a policy that requires user presence, unprivileged malware can import the blob and produce signatures itself. It signs a handshake to Google's cloud authenticator, which happily returns a valid WebAuthn assertion. No admin rights, no biometric prompt, no device unlock. One catch: because the identity key signed rather than a user-verification key, the assertion's UV flag stays 0. Hold that thought.

The middle rung, Silver Pass-ta-key, fixes that "problem" for the attacker. Google's onboarding leaves the account in a uv_key_pending state on first use, and the cloud authenticator never checks the provenance of a newly registered UV key — no attestation that it came from real hardware. So malware deletes the enclave state, forces re-onboarding, and enrolls its own software-generated UV key. Now it can mint assertions with the UV flag set to 1, from any machine, long after the victim's laptop is offline. The verification bit that's supposed to mean "a human touched a fingerprint sensor" now means "someone owned this box once."

The top rung, Golden Pass-ta-key, is the domain-admin equivalent. The Security Domain Secret — a 32-byte symmetric master key that decrypts every passkey synced to that Google account — was supposed to live only inside the cloud enclave. Unit 42 found it sitting in plaintext in Chrome's device logs and process memory during registration and recovery. Grab it and you can decrypt and export the private keys for all of the user's passkeys and rehydrate them on another system. There is no rotation or revocation for this secret. Changing your Google Password Manager PIN does not obviously kill it.

This is not passkeys breaking. It's the sync layer.

The important editorial line: none of this breaks FIDO2 cryptography, and none of it touches a hardware-bound passkey on a YubiKey, a phone's secure enclave used device-locally, or a platform authenticator that never syncs. Every path starts from malware already executing on the victim's Windows box. If you're picturing this as "passkeys are broken," recalibrate — the correct read is narrower and, honestly, more uncomfortable: the moment you decided to make passkeys portable by syncing them through a browser-managed cloud enclave, you reintroduced an extractable, replayable secret. Convenience clawed back exactly the property the standard was built to remove.

That's the trade the industry mostly buried in the marketing. Synced passkeys were pushed hard precisely because device-bound keys have a brutal UX failure mode — lose the device, lose the account. Sync solved recovery. It also created a master key, an onboarding state machine, and a re-registration flow, and each of those is now attack surface that a hardware key simply doesn't have.

What relying parties actually need to do

Here's the part every developer shipping WebAuthn should internalize, because the research already ran the experiment for you. Unit 42 tested real services. GitHub rejected the forged assertions. eBay accepted them — until it patched after disclosure. The difference was one thing: GitHub set userVerification: "required" and validated the UV flag in the returned assertion. eBay requested UV but didn't enforce it on the response, which quietly collapsed its MFA into single-factor.

So the concrete checklist:

• Enforce UV on the server, not just in the request. Setting userVerification: "required" in PublicKeyCredentialRequestOptions is a hint to the client. It means nothing unless your backend rejects any assertion where authenticatorData UV bit isn't 1. If you're on a library, confirm it's actually asserting this — some default to "preferred" and never check.
• Don't treat the UV flag as a human-presence oracle. Silver Pass-ta-key sets UV=1 with no human involved. UV enforcement stops the basic attack, not the escalated one. Layer risk signals — new device, impossible travel, sudden re-enrollment — on top.
• Consider attestation for high-value flows. WebAuthn attestation lets you demand evidence a credential came from genuine hardware. It's a privacy and UX cost most consumer sites skip, but for a crypto exchange or an admin console it's the difference between "a synced key" and "a key I can trust the origin of."
• Watch signature counters, even though sync makes them lousy. Google itself conceded that globally consistent counters are hard across synced devices. They're not useless as an anomaly signal.

Google has plugged the most embarrassing hole — the master key in Chrome's logs (issue 464305542) — but the architectural gaps around UV-key attestation and a non-revocable domain secret are still open, and there are no CVEs and no in-the-wild exploitation reported. Treat this as a design critique with working proof-of-concepts, not a fire drill.

The bottom line for anyone building passwordless auth: passkeys still kill phishing, and that's a real win worth shipping. But if your threat model includes malware on the endpoint — and for anything valuable, it should — a synced consumer passkey is closer to a very good password manager than to a hardware token. Validate user verification server-side, gate your crown-jewel actions behind attestation or step-up, and stop letting "unphishable" quietly stand in for "secure against a compromised device." Those are two different promises, and only one of them is on the box.