Passkeys are lauded as a significant advancement in authentication, offering a passwordless method that leverages cryptographic keys stored on a user's device. They are designed to be more secure than traditional passwords, resistant to phishing, reuse, and guessing, and often incorporate biometric or PIN verification. However, a new report by **Palo Alto Networks' Unit 42** details three sophisticated attacks that demonstrate how malware on an already compromised **Windows** device can undermine the security of **Google Password Manager's** synced passkeys. These attacks, collectively named **Pass-ta-key**, do not break the underlying cryptography of passkeys but rather exploit flaws in how **Chrome** and Google's cloud authenticator manage device trust, onboarding, recovery, and synced credentials. ### Pass-ta-key: Impersonating Trusted Devices The first technique, **Pass-ta-key**, allows unprivileged malware to impersonate a trusted device and request a valid authentication response for a victim's passkey. The malware abuses Chrome's **TPM**-backed device identity key to sign a request sent to Google's cloud authenticator. Crucially, this can be achieved without administrator privileges, user interaction, biometrics, or unlocking the device. Google's cloud authenticator then treats the request as legitimate, returning a signed authentication response (an 'assertion') that can be used to log in. A critical caveat is that the assertion includes a 'User Verified' flag. If a service properly requires and validates this flag, the attack will fail. **Unit 42** successfully tested this against **eBay**, which initially did not properly validate the flag, but subsequently fixed the issue. The attack failed against **GitHub**, which correctly checked the flag.  ### Silver Pass-ta-key: Registering Malicious Verification Keys The second technique, **Silver Pass-ta-key**, escalates the threat by enabling attackers to register their own user-verification key with Google's cloud authenticator. Malware on the compromised device can force Chrome to re-register by invalidating its existing verification key or deleting local passkey state files. During this re-registration process, the attacker can register a user-verification key they control because the cloud authenticator reportedly does not validate whether the new key originated from trusted hardware. Once registered, Google accepts requests signed with the attacker's key as proof of user verification, even for accounts that strictly require and validate it. This allows the attacker to authenticate from another system without further access to the victim's computer. ### Golden Pass-ta-key: Extracting the Master Key The most severe attack, **Golden Pass-ta-key**, allows malware to obtain the master key, known as the 'security domain secret' (SDS), used to encrypt all passkeys synced through the victim's **Google Password Manager** account. This SDS is temporarily sent to Chrome during device registration or account recovery. Initially, **Unit 42** found the SDS exposed in plaintext within Chrome's internal **FIDO** logs. While Google has since removed it from the logs, the SDS is still sent to Chrome and remains temporarily accessible in the browser's process memory. An attacker who forces re-registration can extract the SDS directly from memory. Possession of the SDS enables the attacker to decrypt the victim's synced passkey records and recover their private keys, which can then be used to impersonate the victim and sign into accounts. Furthermore, **Unit 42** warns that Google's current implementation provides no mechanism to rotate or revoke the SDS, meaning current and future synced passkeys remain protected by the same compromised secret. ### Recommendations and Implications While passkeys remain a more secure alternative to traditional passwords, these attacks highlight that they do not entirely mitigate the risks posed by sophisticated malware already present on a compromised device. **Unit 42** recommends that websites rigorously require and properly validate user verification. Credential managers should also implement stronger validation for newly registered device keys, harden recovery and re-registration processes, and prevent master keys from being accessible in browser memory. **Unit 42** responsibly disclosed these vulnerabilities to Google and reported related user-verification flaws to affected services, including **eBay**, prior to public disclosure.