Security researchers at Palo Alto Networks' Unit 42 have disclosed three novel attacks—collectively dubbed Pass-ta-key—that allow malware on compromised Windows devices to abuse Google Password Manager's synced passkeys. The attacks bypass user verification, extract passkey private keys, and enable account takeover without breaking passkey cryptography.

All three techniques require malware to already be running on the victim's computer and target Chrome on Windows devices equipped with a Trusted Platform Module (TPM). Google has partially addressed the issues, but fundamental architectural weaknesses remain.

Background: How Google Passkey Sync Works

Passkeys are passwordless credentials using cryptographic key pairs stored on user devices. The private key never leaves the device; authentication uses the device's TPM to sign challenges. Google Password Manager syncs passkeys across devices via its cloud authenticator service.

When a device registers with the cloud authenticator, it receives a device identity key (backed by the TPM) and a user verification key (for PIN/biometric proof). The cloud authenticator also holds a security domain secret (SDS)—a master key encrypting all synced passkeys for that account.

Attack 1: Pass-ta-key — Impersonating a Trusted Device

The first technique allows unprivileged malware to impersonate the victim's trusted device and request valid authentication assertions for any synced passkey.

How It Works

1. Malware uses Chrome's TPM-backed device identity key to sign a request to Google's cloud authenticator
2. The cloud authenticator treats the request as coming from the victim's trusted computer
3. It returns a signed authentication assertion (including the private key operation result)
4. The assertion includes a User Verified (UV) flag indicating whether biometric/PIN verification occurred

Limitation

The attack fails against services that properly require and validate the UV flag (e.g., GitHub). However, Unit 42 successfully tested against eBay, which required user verification but did not validate the UV flag. eBay has since fixed this.

Attack 2: Silver Pass-ta-key — Registering an Attacker-Controlled Verification Key

This technique goes further by letting attackers register their own user-verification key with the cloud authenticator, bypassing UV flag checks entirely.

How It Works

1. Malware forces Chrome to re-register the device by invalidating its existing verification key or deleting local passkey state
2. During re-registration, the attacker registers a user-verification key they control
3. The cloud authenticator does not validate whether the new key originated from trusted hardware (TPM)
4. Google accepts requests signed with the attacker's key as proof of user verification

Impact

Once the malicious key is registered, the attacker can authenticate from any system without further access to the victim's computer. This defeats the primary security model of passkeys.

Attack 3: Golden Pass-ta-key — Extracting the Master Encryption Key

The most severe technique allows malware to obtain the security domain secret (SDS)—the master key encrypting all passkeys synced to the victim's Google Password Manager account.

How It Works

1. The SDS is temporarily sent to Chrome when a device registers or recovers account access
2. Unit 42 initially found Chrome exposed the SDS in plaintext through internal FIDO logs
3. Google removed the SDS from logs after disclosure, but the secret is still sent to the client and remains accessible in Chrome's process memory
4. If the attacker forces re-registration and knows the memory pattern, they can extract the SDS directly

Impact

With the stolen SDS, the attacker can:

• Decrypt all current synced passkey records and recover private keys
• Transfer keys to another system and impersonate the victim
• Decrypt future passkeys synced to the account (no key rotation mechanism exists)

Google's current implementation provides no way to rotate or revoke the SDS.

Affected Platforms and Mitigations

Successfully Tested Against

• eBay (Attack 1): Required UV but didn't validate flag — fixed after disclosure

Properly Protected

• GitHub (Attack 1): Validates UV flag — attack fails
• Services requiring and correctly validating user verification

Not Tested / Unknown

• Google services, Microsoft, Apple, other major relying parties

Unit 42 Recommendations

For Relying Parties (Websites/Services)

1. Require and properly validate user verification — check the UV flag in authentication assertions
2. Implement additional signals — device fingerprinting, behavioral analysis, risk-based auth

For Credential Managers (Google, Apple, Microsoft, etc.)

1. Validate newly registered device keys — ensure they originate from genuine TPM hardware
2. Harden recovery and re-registration flows — require additional verification for device re-registration
3. Prevent master keys from becoming accessible in browser memory — use hardware-backed key storage, zeroize memory after use
4. Implement SDS rotation/revocation — allow users to rotate the security domain secret

For Users and Organizations

1. Passkeys remain significantly safer than passwords — these attacks require pre-existing malware
2. Keep devices malware-free — endpoint protection, regular scans, least-privilege practices
3. Monitor for anomalous passkey registrations — unexpected new devices on accounts
4. Consider hardware security keys (FIDO2) for highest-value accounts — not vulnerable to these sync attacks

Detection and Response

Behavioral Indicators

• Chrome process accessing FIDO/log files unexpectedly
• Multiple rapid device registrations for same Google account
• Passkey authentication from geographically impossible locations
• Memory injection into Chrome process targeting FIDO components

Response Actions

1. Revoke all passkeys for affected Google account (via Google Account security settings)
2. Rotate Google account password and re-enroll passkeys on clean devices
3. Scan for malware — focus on info-stealers targeting browser data
4. Audit relying party logs for authentication anomalies

Key Takeaways

1. Passkeys don't eliminate malware risk — they shift the attack surface to sync/recovery mechanisms
2. Cloud-backed sync introduces centralization risk — a single SDS protects all synced passkeys
3. TPM-backed device identity ≠ user presence — device keys can be used by malware on the same machine
4. UV flag validation is critical — relying parties must enforce it; Google's authenticator should reject assertions without UV for sensitive operations
5. Memory safety matters — secrets in browser process memory are extractable by co-resident malware

Conclusion

The Pass-ta-key attacks reveal fundamental tensions in passkey synchronization: convenience (cross-device access) vs. security (hardware-bound keys). Google's cloud authenticator architecture—while enabling seamless sync—creates a high-value target where a single master key protects all passkeys, and device re-registration flows lack hardware validation.

Until credential managers implement SDS rotation, hardware-validated device registration, and memory-hardened secret handling, passkey sync remains a calculated risk. For now, passkeys are still far superior to passwords, but organizations should treat synced passkeys as "password-equivalent" for threat modeling: assume malware on a device can eventually access them.

---

Sources:

• Unit 42: Passwordless Authentication Security Risks
• BleepingComputer: New Pass-ta-key Attacks
• Google Passkey Documentation