SURIQ
Passkeys are supposed to end the era of stolen passwords. New research from Palo Alto Networks Unit 42, published on August 3, shows that the promise depends entirely on how each website implements the standard. Unit 42 demonstrated that malware running as an ordinary, unprivileged user on a Windows PC can copy the secret material behind Google Chrome's synced passkeys and replay it to sign in as the victim, even when the account has two-factor authentication turned on.
None of this breaks the underlying FIDO2 and WebAuthn standards that power passkeys. It exploits the gap between what those standards assume and what real deployments actually check. For defenders, that makes it one of the more useful pieces of identity research this year, because the fix is concrete and it lives on your side of the login.
How Chrome stores a passkey
When you use a passkey backed by Google Password Manager, the private key does not simply sit on your laptop. In a companion post on the architecture, Unit 42 traced how Chrome talks to a cloud authenticator during login. At device setup, Chrome generates two hardware-backed key pairs in the Trusted Platform Module (TPM), the security chip on the machine: an identity key that stands for the physical device, and a user verification key that is released only by a local gesture such as Windows Hello, a fingerprint, or a PIN. The passkey private keys are encrypted with a cloud-managed Security Domain Secret, so the cloud, not the laptop alone, signs each login.
The one bit that decides everything
Buried in every WebAuthn login response is a single flag called User Verified (UV). It is the bit that says a human just proved they were present with a biometric or PIN, not merely that the right device answered. Unit 42's central finding is that many websites ask for user verification but never actually check that this bit is set in the response they get back. The entire security difference rides on that one flag inside the login data.
When a site skips that check, a passkey stops being two things you need (a trusted device plus a verified human) and becomes one (just the device). Copy the device's identity key and you can sign in, Unit 42 showed, even though the account still demands multi-factor authentication. That is the whole game.
Three ways to steal the key
Unit 42 named its techniques after the classic Pass-the-Hash family, where a stolen credential is replayed rather than cracked. All three share one precondition: code already running on the target machine.
- The basic attack pulls the wrapped device identity key off disk and uses standard Windows signing interfaces to answer login challenges, with no biometric prompt and no user interaction.
- A second variant forces the browser to re-enroll and slips an attacker-controlled verification key into that setup window, so the attacker can later authenticate remotely without ever touching the victim's device.
- The most severe variant lifts the cloud Security Domain Secret out of Chrome's memory during a re-registration, which decrypts every synced passkey and grants durable, device-independent access.
Unit 42 says a proof of concept exists and demonstrated each flow on video. In keeping with responsible reporting we are not linking to or reproducing offensive tooling; the primary sources above carry the technical detail.
Who was actually exposed
The real-world exposure depends on the relying party, and Unit 42's own testing shows the split clearly. It reported that GitHub validated the user-verified flag correctly, so the account-takeover step failed there. It said eBay initially did not validate the flag and closed the gap after Unit 42's disclosure. On the platform side, Unit 42 reported that Google removed a debug log that had exposed the Security Domain Secret in plaintext. No CVE was assigned; these were implementation and validation gaps addressed through disclosure rather than a single product bug.
What defenders should do now
There are two audiences here, and each has a clear action.
If you run a login service (a relying party): the durable fix is to require user verification and then actually validate the UV bit in every authentication response, not just set the option and trust it. Confirm where any newly enrolled device key came from and check its attestation before trusting it, so an attacker cannot quietly register one of their own. This is a server-side change you control, whatever browser or password manager your users bring.
If you defend endpoints: every one of these attacks needs malware on the machine first, and that precondition is your advantage. The exposure is an endpoint-compromise problem wearing an identity costume, so the detections that catch information-stealing malware catch this too. Watch for unexpected processes touching the browser profile and its passkey state files, for repeated or unnecessary re-onboarding and account-recovery flows, and for unusual device enrollments against the account. On a monitored fleet, file integrity monitoring over the browser's credential state and alerting on anomalous access to it turn a silent key theft into an event you can actually see. For your highest-value accounts, a FIDO2 hardware security key keeps the private key off the general-purpose machine entirely, out of reach of any software running on it.
The headline is not that passkeys failed. It is that "passwordless" moved the hard part from the user to the implementer, and this research is a precise map of where implementers are still cutting corners.