In-app reader
17 min read
Related Products CortexCortex Cloud
By:
Published: August 3, 2026
Categories:
Tags:
Share
This article analyzes new attack classes against passwordless authentication, focusing on Google’s synced passkey ecosystem and the Cloud Authenticator used by desktop clients. The attacks demonstrate how malware on a compromised endpoint can misuse onboarding, recovery and device trust workflows to take over passkey-protected accounts. We show how an attacker can authenticate without user interaction, bypass user verification requirements and extract all synced passkey private keys.
After decades of breaches and billions in losses, the attack vectors that defined the era of passwords and shared secrets are finally starting to fade. Passkeys replace passwords and traditional multi-factor authentication (MFA) with public-key cryptography, decreasing entire classes of attacks that have dominated the threat landscape for years.
With no shared secret to steal, reuse or phish, many of an attacker’s most reliable tools are becoming obsolete. This represents a significant disruption for the credential theft market.
Attackers, however, persist. They evolve, and defenders must prepare for a new generation of attacks. As passkeys become widely adopted and scale to billions of accounts, defenders must prepare for new attack surfaces, some of which we disclose in our research.
This article is part 3 in our series examining passkey adoption from a security perspective. If you haven’t read the previous parts, we recommend starting here:
Part 1: The Art of the Invisible Key – Passkey Global Breakthrough
Part 2: Google Authenticator: The Hidden Mechanisms of Passwordless Authentication
Palo Alto Networks customers are better protected from this new attack vector through the following products and services:
If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.
Related Unit 42 Topics Google Authenticator, Cloud, Malware
Google’s synced passkey implementation is particularly instructive due to its scale and how it creates a higher standard for private key protection in two critical ways:
Private keys are generated and used within a cloud-enclave isolation environment
Hardware-backed, client-device-bound keys control access to cloud-based cryptographic operations, attesting to the user’s presence on a trusted device
This article builds on the architectural analysis from Part 1 and Part 2 of our previous articles in this series. We now shift from how passkeys are built and deployed to how attackers can misuse them.
We present three novel attacks that enable account takeover of passkey-protected accounts. Each attack challenges a different core assumption of passkey authentication security. When a client authenticates with a passkey, the following is expected:
Users provide explicit consent on the device to verify user presence
For MFA, users must also unlock the device to verify biometric (i.e., something you are) or knowledge-based (i.e., something you know) authentication factors
Passkey private keys cannot be shared or copied
The Google documentation reflects these core assumptions, describing the passkey login process as a secure alternative to passwords (as shown in Figure 1).
Challenging these expectations is a category of attacks we've nicknamed Pass-ta-key. This playful, layered name blends the word passkey and the phrase “pass the key,” with a light nod to the concept of plate of pasta, illustrating how tangled this key implementation can get.
These attacks each expose a different weakness in practice:
**Pass-ta-key attack: **An attacker takes over an account protected by a Google-synced passkey using malware running on the victim’s device, without requiring privilege escalation, device unlock or user interaction
**Silver Pass-ta-key attack: **An attacker deceives the Google Cloud Authenticator into believing the victim has unlocked the device with biometrics, leading to full account takeover without using the victim’s device during authentication
**Golden Pass-ta-key attack: **An attacker can extract all synced passkeys in a form that allows them to be shared or sold on the credential black market
These attacks demonstrate how malware can exploit synced passkeys, even when providers add hardware-backed protections to secure credentials within the cloud authenticator.
Disclaimer: This research involved responsible and ethical security analysis. We responsibly disclosed all presented exploits. The cloud authenticator model is used by various passkey providers across multiple browsers and platforms. This work, however, focuses on Google Password Manager in Chrome on Windows, specifically on devices equipped with a Trusted Platform Module (TPM). All presented attacks rely on malware already existing on the victim’s device during the initial stage.
Before attempting any of the attacks, the attacker needs visibility into how passkeys are used within the victim’s account. On a compromised endpoint, this visibility is readily available.
Chrome locally stores synced passkey data as part of its synchronization process. On Windows, Chrome persists this data as proto-encoded WebauthnCredentialSpecifics records, which represent synced WebAuthn credentials, within its sync database:
%LocalAppData%\Google\Chrome\User Data<Profile>\Sync Data\LevelDB
Accessing these records does not require elevated privileges. The records allow an attacker to enumerate where the victim uses passkeys, along with associated usernames, credential identifiers and the encrypted private key.
After identifying a service where the victim uses passkeys, an attacker can attempt to authenticate as the victim.
The primary challenge for attackers is bypassing the protection of the private key, which is used to sign authentication challenges. This private key is secured by a master key. While an encrypted version of this master key is stored on each client device, only the cloud authenticator can decrypt it.
Despite this security, the architecture remains vulnerable to exploitation. The following sections detail methods attackers could use to exploit system mechanisms, authenticate as the victim, and compromise passkey-secured accounts.
Our first attack is the most straightforward approach, which involves taking over a passkey-protected account by mimicking the behavior of Google Password Manager and Chrome during legitimate authentication. In a normal flow, Chrome sends a request to the cloud authenticator, signed using the device’s hardware-backed keys.
Unlike a legitimate user flow that requires user interaction and device unlock, this attack shows how malware can obtain the required signature silently, without user consent, biometrics, device unlock or elevated privileges.
To understand this, we focus on Chrome’s device identity key, which represents client device possession to the cloud authenticator. As previously explained ( part 2: Login with Synced Passkey and Device Key Signature ), generating the required assertion involves signing data sent to the cloud authenticator using one of the device’s hardware-backed keys. This is the identity key or the user verification key (UV key).
Although both keys are hardware-bound, they are not accessed in the same way. For the identity key, Chrome creates the conditions that allow it to request a signature while running as a user without elevated privileges and without triggering device unlock protections.
On Windows, Chrome calls the NcryptCreatePersistedKey function without assigning a key name, making the TPM-backed key ephemeral and preventing it from being persisted to disk. Instead of storing the private key within the TPM, Chrome calls NcryptExportKey to export the key as an NCRYPT_OPAQUE_KEY_BLOB , which instructs the TPM to encrypt the private key using a TPM-resident key. The resulting blob is stored as wrapped_identity_private_key in the passkey_enclave_state file, making it available for future use on the same physical TPM.
Malware can extract this wrapped_identity_private_key from disk or Chrome’s memory. It can then invoke cryptographic operations using standard Windows Cryptography API: Next Generation (CNG) APIs ( NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash), without elevated privileges, mimicking Chrome’s own actions.
Having established that malware can generate the required signature, we now detail the full Pass-ta-key attack flow (as shown in Figure 2). This flow allows a remote attacker with unprivileged malware on the victim’s device to authenticate as the victim.
The attack flow consists of the following phases:
After collecting the victim’s synced passkey records (Stage Zero: Reconnaissance), the attacker selects a targeted account and initiates a passkey login
The relying party responds with a fresh authentication challenge
The attacker initiates a WebSocket handshake with the Google Cloud Authenticator
Using the hash of that handshake, the attacker interacts with the victim’s TPM and uses the extracted identity key to sign the handshake hash together with the assertion request
The attacker sends an assertion request to the cloud authenticator, including the identity key signature
From the cloud authenticator’s perspective, the request appears to be a trusted device making a valid request, so it produces a valid assertion response
This assertion is then forwarded to the relying party, completing authentication and giving the attacker full control of the victim’s account
Video 1 demonstrates the attack as it would unfold in practice. (We have blurred the names of the relying parties to avoid naming.)
_ Video 1. Example of a successful Pass-ta-key attack. _
As the video begins, the screen splits between the attacker's terminal and the victim's desktop. The video first shows the attacker establishing a command-and-control (C2) listener, passively waiting for victims to connect.
On the victim’s machine, the Trojan executes as a standard user, without elevated privileges. Once active, it collects the victim’s encrypted, synced passkeys and sends them back to the attacker’s C2 server. This provides visibility into the victim’s available passkeys.
The attacker selects a target, such as a messaging application account protected by a passkey, navigates to the application and chooses Login with passkey . The relying party then responds with a fresh authentication challenge.
Next, the attacker initiates communication with the Google Cloud Authenticator. After completing the handshake, the attacker triggers the Trojan to use the device’s identity key to sign the required data. Specifically, it uses the hash of the handshake combined with the hash of the serialized assertion request.
The attacker then attaches this signature to the request sent to the cloud authenticator. The cloud authenticator returns the requested assertion. The attacker forwards this valid assertion to the relying party and successfully logs in as the victim.
The Pass-ta-key attack is effective when the relying party does not strictly require user verification. Many relying parties configure WebAuthn’s userVerification parameter as preferred rather than required to support diverse devices and user experiences, making them susceptible to this attack.
When a relying party explicitly requires user verification, one would expect the cloud authenticator to reject requests that are not signed using a key gated by PIN or biometric verification. Surprisingly, this is not the case.
The cloud authenticator returns a valid assertion regardless of whether the request was signed using the identity key or the UV key. The difference comes down to a single bit in the authenticator data, the User Verified (UV) flag.
When the assertion is signed using the UV key, this flag is set to 1. When it is signed using the identity key, the flag remains 0.
While the Pass-ta-key attack produces cryptographically valid assertions matching the relying party’s public key, our testing shows attacks typically fail when user verification is required because the UV flag remains unset. For example, when attempting the attack against a passkey-protected GitHub account, the attacker receives an error message, as shown in Figure 3.
Although authentication is typically rejected when user verification is required, this behavior is not always consistently enforced across relying parties. In our testing, we identified relying parties that accepted authentication because they did not properly validate the UV flag. This allowed the attack to succeed despite the absence of user verification.
The lack of validation effectively reduces the authentication process to a single factor. By compromising only the device identity key, the attacker is able to authenticate successfully and take over the account, even though MFA is required.
We reported this issue to the affected relying parties.
Video 2 demonstrates this behavior in practice on eBay. Although eBay sets the userVerification parameter to required , the demo recording shows a successful passkey login using the described technique, without any user interaction or additional authentication factors.
We captured this recording before eBay fixed the issue. Following our report, eBay addressed this verification gap and now properly validates the UV flag.
Video 2. Pass-ta-key attack succeeds despite the absence of user verification, even when the UV is required.
When an account is protected by stronger authentication requirements, such as for financial or federal identity systems, the attacker must also bypass user verification. This initially appears to be a significant challenge.
The cloud authenticator requires a message signed with the UV key to set the UV flag. Client interaction controls access to this key, as the OS validates the user via the same mechanism used for device unlock. Without escalating to system privileges or physical access to the victim device, an attacker has no apparent path to obtain such access.
Attackers can bypass this challenge through the following mechanism:
Instead of bypassing access to the UV key, the attacker invalidates the existing key registered in the cloud authenticator and registers a newly generated key under their control
Once the attacker-controlled key is registered, any message signed with it is accepted by the cloud authenticator as if the user had successfully performed device unlock
Figure 4 demonstrates the attacker-side authentication flow in the Silver Pass-ta-key attack, focusing on the authentication phase after the attacker-controlled UV key is registered.
This approach has important implications. It allows the attacker to fully automate authentication across all the victim’s accounts without human interaction, even where user verification is enforced. Furthermore, the attacker no longer needs live access to the victim’s device during authentication.
Unlike the previous attack, which required active malware on the victim’s device for each authentication, the Silver attack provides reusable access. This allows the attacker to access the victim’s passkey-protected accounts from their own environment, without requiring the victim’s device to be online or active. Ultimately, this enables account takeover across all passkeys associated with the victim without requiring elevated privileges.
To carry out this attack, the first objective is to invalidate the existing UV key associated with the target device. From the previous attack, we learned how an attacker can use unprivileged malware to sign attacker-controlled requests with the device identity key and send them to the cloud authenticator. The attacker can leverage this capability to issue a device/forget command on behalf of the victim. A simpler option is to directly delete the victim’s passkey_enclave_state file, as there are no built-in protections that prevent its removal.
Regardless of the method, the next time the user attempts to use a passkey, Chrome is forced to re-onboard the device. This occurs either because Chrome no longer has access to the device key or because the cloud authenticator no longer recognizes the device as registered.
On Windows, device onboarding is only completed after the second use of a passkey on the same device. During the first use, Chrome begins onboarding with the cloud authenticator in the background while prompting the user to enter the Google Password Manager (GPM) recovery PIN.
If Chrome were to create the UV key at this point, it would also trigger a Windows Hello prompt, requiring the user to authenticate again using biometrics or a PIN. Since both steps may involve a PIN, presenting them back-to-back in the same flow can be confusing and lead to user errors. To avoid this, Chrome defers the creation of the UV key.
Instead, the device is initially registered in a uv_key_pending state. During this first interaction, the GPM recovery PIN satisfies user verification, and the actual UV key is only created and registered during the next passkey use, when the additional prompt is no longer needed.
After forcing the victim into this re-registration state, the attacker can exploit the uv_key_pending condition. In their own environment, the attacker generates an asymmetric key pair. They then send a device/add_uv_key command to the cloud authenticator, providing the attacker-controlled public key as the UV key.
The cloud authenticator does not validate the attestation of newly registered UV keys to verify whether they originate from secure hardware. As a result, the attacker-controlled key is stored alongside the legitimate device identity key:
devices[device_id] = { hw: identity_public_key, uv: (Attacker-controlled) uv_public_key }
1
2
3
4
5
devices [ device_id ] =
{
hw : identity_public_key ,
uv : ( Attacker - controlled ) uv_public_key
}
From this point on, the attacker can use the forged UV key to request signatures for any passkey associated with the victim and obtain assertions with the UV bit set. This provides access to high-value accounts even when user verification is enforced and validated.
In this attack, the attacker effectively gains the cloud authenticator’s superpower, the ability to decrypt synced passkeys. This is particularly impactful because it undermines the intended protection mechanism.
The passkey’s private key is protected using a symmetric master key called the security domain secret (SDS). This master key is not directly accessible, it is stored on the device as an encrypted wrapped_secret . Only the cloud authenticator can decrypt this wrapped_secret using its device-specific key ( wrapping_key ) within its isolated environment, as noted in Figure 5.
Figure 5. Synced passkey decryption inside the cloud authenticator.
This design aims to protect synced passkeys even if the client device is compromised. As Google noted in response to one of our vulnerability reports:
“The (cloud) enclave authenticator’s primary function is to make it difficult to steal passkey private data, which would be an obvious target for malware if it were locally available.”
The security of this model ultimately hinges on the protection of the 32-byte SDS. If an attacker is able to obtain the SDS, they effectively gain the ability to decrypt all synced passkeys for that account. This allows them to authenticate as a fully verified user and take over every
…(truncated for reading performance)
Discussion
Sign in to join the discussion.