Security researchers have disclosed three attack techniques targeting Google Password Manager on Chrome for Windows that could allow malware running on a compromised device to gain access to passkey protected accounts without requiring a fingerprint, PIN, or visible authentication prompt. The research, published by Unit 42, describes the techniques as Pass ta key, Silver Pass ta key, and Golden Pass ta key, with the most advanced method targeting the Security Domain Secret used to decrypt synchronized passkey private keys. According to the researchers, the attacks do not compromise the cryptographic foundations of passkeys. Instead, they focus on weaknesses in the surrounding implementation, including how Chrome stores device keys, re-enrolls trusted devices, and verifies user authentication during the sign in process. The report does not describe evidence of these techniques being exploited in real world attacks and does not assign Common Vulnerabilities and Exposures identifiers or identify affected Chrome versions.
The research is limited to Google Password Manager running in Chrome on Windows systems equipped with a Trusted Platform Module, and every attack scenario assumes that malware has already compromised the victim device. Researchers explained that Chrome stores synchronized credential records locally, allowing malware operating with ordinary user privileges to collect metadata related to passkeys, including usernames, relying party information, credential identifiers, and encrypted private key material. The first attack method, known as Pass ta key, abuses Chrome wrapped device identity key by requesting the same Trusted Platform Module to sign attacker controlled authentication requests through Windows Cryptography API Next Generation functions. Researchers stated that Google Cloud Authenticator can return a valid authentication assertion, although the resulting User Verified flag remains unset. According to the Web Authentication specification, websites that require user verification should reject authentication attempts when that verification flag is missing. During testing, GitHub correctly enforced this requirement, while eBay initially accepted the authentication before correcting the validation issue following responsible disclosure.
The second technique, Silver Pass ta key, targets Chrome device re enrollment process. According to Unit 42, malware can force Chrome to re register a trusted device before a legitimate user verification key has been created. During this temporary window, an attacker may register a replacement verification key under their control. Researchers stated that if the service does not verify whether the replacement key originated from secure hardware, future authentication requests signed with the attacker controlled key could include the User Verified flag, allowing repeated account access without requiring the victim original device. The third technique, Golden Pass ta key, focuses on extracting the 32 byte Security Domain Secret from Chrome process memory after malware triggers device re enrollment. Researchers stated that obtaining this secret could allow attackers to decrypt synchronized passkey private keys from their own environment after the initial compromise. Chromium source code confirms that the secret is temporarily stored within Chrome memory, although the complete attack chain and long term persistence remain based on Unit 42 analysis. The report also notes that Google previously removed an earlier Security Domain Secret exposure from Chrome FIDO logging, but researchers maintain that the secret still temporarily exists in memory.
The disclosure also highlights several defensive measures for website operators and credential providers. Researchers recommend that relying parties configure authentication systems to require user verification and validate the returned User Verified flag instead of assuming verification occurred automatically. They also recommend stronger hardware attestation for newly enrolled authentication keys, more secure re registration and recovery processes, tighter protection for locally stored passkey information, and reducing exposure of master secrets within client memory and system logs. According to the report, there is currently no publicly documented method for users to determine whether their Security Domain Secret has been compromised. Google support documentation allows users to change their Google Password Manager PIN or delete stored Password Manager data, but it does not explain whether these actions invalidate a previously stolen Security Domain Secret. Unit 42 stated that it disclosed its findings responsibly, while Google and Palo Alto Networks were contacted for additional clarification regarding the reported techniques and any remediation measures that may have been implemented.
Follow the SPIN IDG WhatsApp Channel for updates across the Smart Pakistan Insights Network covering all of Pakistan’s technology ecosystem.
