Passkeys are not bulletproof

Google's synced passkey system, built on cloud enclaves and TPM-bound keys, faces three new attack classes. Researchers at Palo Alto Networks' Unit 42 demonstrated that malware on a compromised Windows endpoint can take over passkey-protected accounts without user interaction, bypass user verification, and extract all synced private keys for offline use.

These attacks, collectively dubbed "Pass-ta-key," target the gap between passkey promises and real-world implementation. Each exploits a different weakness in Google Password Manager's architecture.

Attack 1: Pass-ta-key — silent authentication

The simplest attack mimics legitimate Chrome behavior. Malware running as a standard user on a Windows device can sign authentication requests using the device's TPM-backed identity key, without triggering device unlock or requiring any user consent.

Chrome stores a wrapped identity private key in %LocalAppData%\Google\Chrome\User Data\\passkey_enclave_state. This blob is encrypted by the TPM and can be imported back via standard CNG APIs (NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash) without elevation.

The attack flow:

  1. Malware collects synced passkey records from Chrome's LevelDB sync database (%LocalAppData%\Google\Chrome\User Data\\Sync Data\LevelDB). These records contain WebauthnCredentialSpecifics protobufs with usernames, credential IDs, and encrypted private keys.
  2. Attacker initiates a passkey login on a target service.
  3. Attacker opens a WebSocket connection to Google's Cloud Authenticator.
  4. Malware signs the handshake hash and assertion request using the extracted identity key.
  5. Cloud authenticator sees a valid signature from a trusted device and returns a WebAuthn assertion.
  6. Attacker forwards the assertion to the relying party, gaining full account access.

The attack works even when the relying party sets userVerification: "preferred" (the default for many services). But the researchers found a bigger problem.

Attack 2: Silver Pass-ta-key — bypassing biometrics

When a relying party requires user verification (e.g., userVerification: "required"), the cloud authenticator is supposed to enforce device unlock. Unit 42 found that the authenticator returns a valid assertion regardless of whether the request was signed with the identity key or the UV key.

The UV flag — a single bit in the assertion response — is the only difference. Malware can request an assertion signed with the identity key, and the cloud authenticator sets the UV flag to true anyway.

The researchers demonstrated this by sending an assertion request signed with the identity key to the cloud authenticator. The response included uv: true, and the relying party accepted it. This means biometric checks are effectively optional.

Attack 3: Golden Pass-ta-key — extracting private keys

The most severe attack extracts all synced passkey private keys in a shareable format. The cloud authenticator uses a master key to encrypt private keys, but that master key is stored on the client in an encrypted form.

Unit 42 found that by abusing the recovery workflow, malware can force the cloud authenticator to decrypt the master key and re-encrypt it with a key known to the attacker. The attacker then decrypts all synced passkeys and can use them on any device.

The exact technique involves intercepting the recovery flow and manipulating the enclave state, but the result is clear: the private keys are no longer device-bound.

What this means for developers

These attacks require existing malware on the victim's device. They do not bypass endpoint security; they assume it's already compromised. But they undermine the core promise of passkeys: that a stolen device or malware cannot lead to account takeover.

If you're a developer relying on passkeys for authentication, here's what you need to know:

  • Require user verification server-side. Don't rely on the client's uv flag. Check the userVerified property in the authentication response and reject if false.
  • Consider binding passkeys to hardware. Google's synced passkeys are convenient but vulnerable. Hardware-bound passkeys (like those on YubiKeys) are more resistant to these attacks.
  • Monitor for suspicious authentication patterns. Sudden logins from new devices or unusual times could indicate a pass-the-passkey attack.

The bottom line

Passkeys are a significant improvement over passwords, but they're not a silver bullet. The Pass-ta-key attacks show that cloud-synced passkeys introduce new attack surfaces that malware can exploit. Until providers like Google fix these issues, developers should treat passkeys as a strong factor, not an unbreakable one.

Next steps

Read the full Unit 42 research for technical details and IOCs. If you're building authentication, implement server-side checks for user verification and consider hardware-bound passkeys for high-security accounts. And if you're a Google user, watch for updates to Google Password Manager that address these vulnerabilities.