Synced Passkeys Have a Malware Problem

Passkeys were supposed to be the end of the phishing arms race. Bind the credential to the origin, sign a challenge with a private key that never leaves the device, and the whole industry of look-alike login pages stops working overnight. That part is true, and it still is. What Palo Alto Networks' Unit 42 just demonstrated is that the phishing win quietly bought us a different problem: to make passkeys sync across your phone, laptop, and tablet, the crown jewels have to live somewhere a compromised endpoint can reach.

Their research, published in early August, chains three malware-driven techniques — cheekily named Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key — against Google Password Manager's synced passkeys in Chrome on Windows. None of them breaks a single line of WebAuthn cryptography. They don't need to.

The threat model shifted, and nobody moved the goalposts

Read the marketing and you'd think a passkey is a hardware secret sealed in a TPM or secure enclave, untouchable by software. That's the model for a device-bound passkey — the kind a YubiKey or a non-synced platform authenticator gives you. It's a genuinely great model.

Synced passkeys are a different animal. To appear on every device you own, the private keys are wrapped by a master key — Google calls it the Security Domain Secret (SDS), a 32-byte value — and shuttled through a cloud service Google refers to as the Cloud Authenticator. The security of the whole vault now rests on the onboarding, recovery, and device-trust plumbing around that service. That plumbing runs in Chrome, in userland, on your PC. And that is exactly the seam Unit 42 pried open.

The precondition for all three attacks is malware already running on the victim's Windows machine — as an ordinary user, no admin, no UAC prompt. That's a real bar, and some will wave the research away because of it. Don't. "Attacker has code execution on the endpoint" is not an exotic assumption; it's Tuesday for anyone running an infostealer campaign. The interesting question is what that foothold buys you, and the answer used to be "the passwords in the vault." Now it's "the passkeys too, silently, with no biometric prompt on screen."

What the three attacks actually do

The base Pass-ta-key technique lifts the device identity key — which Chrome stores as a TPM-wrapped blob but does not gate behind device unlock — and replays it through Windows CNG calls (NCryptImportKey, NCryptSignHash) to sign a valid assertion request to the Cloud Authenticator. The malware impersonates a trusted device and gets a working assertion back. No fingerprint, no PIN, nothing rendered to the user.

Silver Pass-ta-key is the nastier one. The malware deletes the local passkey_enclave_state to force the device into re-onboarding, then — during the window where Chrome expects a fresh user-verification key — registers an attacker-controlled UV key. Because the Cloud Authenticator doesn't validate attestation on the new key, it accepts it. The attacker can now produce assertions with the UV flag set to 1, defeating relying parties that demand user verification. This is the Kerberos Silver Ticket idea ported to passkeys, and the name is earned.

Golden Pass-ta-key goes for the vault itself. Trigger the same re-onboarding, then dump Chrome's process memory while the SDS is transiently present during recovery. With the master key in hand, every synced passkey record decrypts. Full portability of the victim's entire passkey collection — the passkey equivalent of stealing the KRBTGT hash. Worse still, as Unit 42 notes, synced passkey systems have no coordinated signature counter, so there's little to detect the cloned credentials being reused elsewhere.

The half that developers own

It's tempting to file this as "Google's problem," and Google does own the biggest pieces — it has already stripped the SDS from Chrome's device-log/FIDO output, where it was sitting in plaintext, and acknowledged the missing attestation validation on re-registered UV keys. But one finding lands squarely on application teams, and it's the one you can fix this sprint.

Several relying parties set userVerification: "required" in their WebAuthn options and then never check the UV bit in the returned authenticator data. Setting the policy is a request to the client; enforcing it is your server's job. Unit 42 reported this gap to eBay, which fixed it. If your login backend looks like this, you have the same hole:

// Requesting UV is not the same as verifying it.
const { authenticatorData } = parseAssertion(response);
const flags = authenticatorData[32];        // flags byte
const userPresent  = (flags & 0x01) !== 0;  // UP
const userVerified = (flags & 0x04) !== 0;  // UV

if (policy.userVerification === "required" && !userVerified) {
  throw new Error("UV required but not asserted");
}

Any conformant WebAuthn library surfaces these flags; the bug is trusting the ceremony to have done what you asked. Audit that check across every RP you operate.

Where this leaves passkeys

Passkeys are still the right call, and this research is not a reason to crawl back to passwords — passwords fail to remote attackers with zero endpoint access, which is a far larger population. But three claims deserve retirement. "Passwordless means unphishable and unstealable" was always overselling it; the honest pitch is unphishable, with theft resistance that depends entirely on how the keys are stored. "Synced and device-bound passkeys are the same security tier" is now demonstrably false — syncing trades hardware isolation for a cloud-recovery surface, and for high-value accounts that trade may not be worth it. And "the TPM protects it" only holds when the key is actually gated behind user verification, which Chrome's device identity key was not.

The practical takeaway for teams shipping FIDO2: pick device-bound authenticators for your most sensitive roles, validate the UV flag server-side, and require attestation when your credential model supports it. And keep investing in endpoint security, because the passkey era didn't abolish the compromised-host threat — it just raised the value of what a foothold can carry off.