- Sources: research, discussion
- Summary: Unit 42 names three attacks: Pass-ta-key, which authenticates with no user interaction, Silver Pass-ta-key, which registers an attacker-controlled user-verification key so the cloud authenticator treats later requests as device-unlocked, and Golden Pass-ta-key, which extracts every synced passkey private key in a form that can be shared or sold. Unit 42 states that Silver Pass-ta-key gives reusable access from the attacker's own environment without the victim's device being online. All three require malware already present on the victim's device in the initial stage, and Unit 42 states no privilege escalation is needed. The research covers Google Password Manager in Chrome on Windows on devices with a TPM. Separately from the three attacks, Unit 42 describes a relying-party implementation failure: a party that requests user verification but never validates the User Verified bit in the returned assertion lets Pass-ta-key succeed where it would normally be rejected, and the post states the attack typically fails against parties that do validate the bit. Unit 42 names eBay as a relying party that accepted the attack despite setting
userVerification to required, and states eBay fixed it after the report. The research does not specify affected Chrome or Google Password Manager versions. - Why it matters: The UV check is the one part of this a service can fix without Google, and the eBay case shows that requesting user verification is not the same as enforcing it on the response.
- Follow-up: Watch for a Google response and for WebAuthn library changes that validate the UV bit by default.
send feedback on this story