Google Password Manager passkeys could be at risk with new ‘Pass-ta-key’ attack

A novel attack dubbed "Pass-ta-key" can exfiltrate synced passkeys from Google Password Manager, undermining the very phish-resistance that passkeys were designed to provide. Passkeys-based on FIDO2 and WebAuthn-were supposed to be the end of credential stuffing and phishing. They bind cryptographic keys to a domain, making them nearly impossible to steal via fake login pages. google rolled out passkey sync in its Password Manager to make the experience seamless across Android, Chrome, and even macOS. But as the "Pass-ta-key" Attack demonstrates, convenience often comes with a dangerous assumption: that the sync mechanism itself is an impenetrable fortress.

We've all heard the pitch: no more passwords, no more SMS 2FA, and just a biometric gesture and you're inIn production environments, our team has migrated dozens of web apps to WebAuthn, enthusiastic about the promise of unphishable credentials. Yet after digging into the latest research around this attack, it's clear the industry overlooked a critical threat vector-the cloud-based store. If a user's Google account is compromised, the attacker can silently replicate their entire passkey collection, possession and all. That's the heart of the Pass-ta-key exploit,, and and it deserves a sober, engineering‑first dissection

Understanding Passkeys: The FIDO2 Promise and Google's Implementation

Passkeys are multi‑device FIDO2 credentials. Each passkey consists of a private key stored on the user's authenticator-be it a phone, a security key. Or a cloud‑synchronized vault. When logging into a website, the browser proves possession of that private key by signing a challenge, without ever revealing the key material. The standard is defined by the W3C WebAuthn Level 2 specification and the underlying FIDO Alliance protocols. Google's twist: they store the private key material inside Google Password Manager, end‑to‑end encrypted (E2EE) with the user's Google account credentials, and then sync it across all devices where the same Google account is signed in.

This sync architecture is what makes passkeys "just work" when you switch from phone to laptop. A passkey created on an Android device becomes available inside Chrome on a Windows desktop, no QR code scanning needed. But the trade‑off is that the Google account itself becomes the root of trust. If that account is compromised, an attacker can request the synced passkey data and-due to how Android's backup and restore mechanisms work-potentially recover usable key material. This isn't a theoretical weakness; it's the exact attack surface that Pass‑ta‑key exploits,

How Google Password Manager Syncs Passkeys Across Devices

To understand the attack, you need to know the sync plumbing. Google Password Manager stores passkey private keys within the same encrypted blob that holds saved passwords, payment methods, and addresses. The blob is protected by a key derived from the Google account password and device‑specific unlock factors. When a user creates a passkey on a new device, the Google servers never see the raw private key; it's wrapped in a Recovery Key that's only accessible after successful account authentication. Google documents this in their passkey rollout announcement

The sync protocol relies on the Google Account Authentication service. After sign‑in, the client requests the encrypted passkey collection from Google's sync servers. Decryption happens locally on the device using a key derived from the account credentials and potentially a hardware‑bound secret if available. This means that possession of the Google account credentials (or session tokens) is enough to fetch the encrypted data. While the encryption is strong, the retrieval mechanism doesn't require a second factor or biometric check beyond the initial Google login-a fact that Pass‑ta‑key leverages ruthlessly.

In many observed configurations, the sync even permits a new device to download the passkey vault as part of the initial device setup, provided the user enters their Google password. Once that happens, the private keys become available to any WebAuthn‑compliant application on that new device. The trust model shifts from "something you have" to "someone who knows your Google password and has a session token. " For a security primitive marketed as phish‑resistant, that's a startling downgrade.

Diving Into the "Pass-ta-key" Attack: A Credential Passing Vulnerability

The name "Pass‑ta‑key" is a play on "pass‑the‑hash" attacks in Windows authentication. Instead of passing a hash, attackers pass a valid Google account session to another machine and replay the passkey sync flow. Researchers demonstrated that if they compromise a user's Google account-via phishing, malware-stealing session cookies, or SIM swap-they can immediately force a download of all synced passkeys onto an attacker‑controlled device. The attack doesn't require the victim's biometric data or any additional per‑passkey verification. The sync protocol trusts the authenticated Google session entirely.

In the proof of concept, the attacker used a stolen authentication token to authorize a new device in Google's ecosystem. That device then initiated a standard password‑manager sync, pulled the encrypted passkey blob. And decrypted it using the same credential‑derived key (or using a previously captured decryption key from device compromise). The result: the attacker gained full passkey access to dozens of services-email, banking, social media-without ever seeing a password or an OTP. This is the core of the Pass‑ta‑key threat.

Notably, the attack doesn't bypass the WebAuthn specification itself. The browser still correctly signs the challenge. And the relying party sees a valid FIDO2 assertion. The problem is that the private key, once synced, is now usable from a rogue device that the service can't distinguish from the legitimate one. This isn't a vulnerability in the cryptographic protocol; it's an implementation‑level flaw in the trust model of cloud‑synced passkeys, one that underscores how syncing can break the "possession" factor.

The Attack Chain: From Google Account Compromise to Passkey Exfiltration

Let's outline the exact steps observed in a realistic exploitation:

• Step 1 - Account takeover: Attacker obtains the Google account password or session token via phishing, info‑stealer malware. Or a credential‑stuffing attack against reused passwords.
• Step 2 - Session cloning: The token is imported into a fresh browser profile on an attacker‑controlled machine, bypassing Google's new device notifications if the attacker uses a cookie replay technique.
• Step 3 - Passkey sync trigger: The attacker navigates to passwords google com or uses a Google service that triggers a sync of Password Manager data. The server treats this as a normal request from an authenticated session.
• Step 4 - Decryption: Because the user's account credential (and sometimes a recovery‑key file stored on a compromised machine) is known, the attacker decrypts the passkey vault locally, unpacking all private keys.
• Step 5 - Replay: The attacker uses the WebAuthn API from the attacker‑controlled browser to sign challenges for any relying party where the victim had a passkey. The biometric gate is irrelevant-the device now holds the key. And a simple system‑level authentication (like a device password) may be the only hurdle.

In production environments, we've seen how single sign‑on (SSO) and seamless sync often make such chained attacks possible. Developers often underestimate the blast radius of a compromised Google account. With passkeys stored there, the blast radius expands from "my email is pwned" to "every FIDO2‑protected service I use is instantly accessible. " The Pass‑ta‑key attack is fundamentally about that blast radius.

Why This Attack Bypasses Traditional Phish-Resistance Guarantees

WebAuthn was designed so that even if a user is tricked on a phishing page, the credential can't be used elsewhere because the private key never leaves the authenticator and the assertion is bound to the origin. For hardware‑bound security keys, this holds true. But in a cloud‑synced model, the private key isn't "non‑exportable" in the deepest sense. Yes, the key material is encrypted at rest on Google's servers, but once an attacker gains access to the Google account, they can replicate the entire authenticator state to a new device. The phish‑resistance guarantee breaks because the attacker doesn't need to phish the passkey itself; they phish the Google account that controls the passkey vault.

Consider a real‑world scenario: a developer uses passkeys for GitHub, AWS console, and their corporate IdP. All passkeys are stored in Google Password Manager. A phishing email targeting their Google credentials succeeds. The developer may have MFA on Google, but if the attacker steals a session cookie, MFA is bypassed. Now the attacker syncs the passkey collection and can commit code, destroy infrastructure, and exfiltrate customer data-with legitimate FIDO2 assertions. No new MFA challenge appears because the relying parties trust the passkey authenticator. This is a massive gap that many enterprise security policies haven't accounted for yet.

Comparing Cloud-Synced Passkeys to Device-Bound Hardware Tokens

Security engineers have long debated the trade‑offs between user experience and true hardware isolation. A YubiKey or FIDO2‑certified security key stores the private key inside a secure element that makes extraction extremely difficult. Even if your machine is completely compromised, the key never leaves the token. Pass‑ta‑key would be infeasible against such a setup because there's no sync endpoint to abuse-each key is physically bound to the token. Google's advanced protection program even requires these hardware keys for high‑risk accounts.

In contrast, a synced passkey is stored in software, encrypted but ultimately accessible after account login. While Google uses hardware‑backed keystores on Android (via Titan M) and TPMs on other platforms to protect decryption keys, the sync pathway remains a soft spot. The decryption key or the recovery mechanism is often tied to the Google account password. An attacker who successfully passes‑the‑hash (or in this case, passes‑the‑token) essentially gains the same primacy as the user. This diminishes the unique "possession" factor that made hardware keys attractive to critical infrastructure operators.

From an engineering perspective, I advise clients that if a service truly demands unphishable authentication, hardware keys remain the gold standard. Cloud‑synced passkeys can be a strong second factor for everyday consumer use, but they shouldn't be the sole authenticator for administrative access when a Google account compromise is a plausible threat. Read more about FIDO2 authenticator types in our guide to WebAuthn best practices

Real-World Exploitation Scenarios: What Developers Must Know

Beyond the theoretical, several real‑world patterns make this attack worryingly feasible. Info‑stealer malware families like RedLine, Raccoon. And Vidar routinely harvest browser session cookies, passwords. And autofill data. In a 2023 report by Group‑IB, session cookie theft was identified as the primary initial access vector for cloud service compromises. If those stolen cookies belong to a Google account with synced passkeys, the attacker doesn't even need the password-just replay the cookie and trigger the sync.

One variation of Pass‑ta‑key uses Android backup APIs. Attackers who compromise a Google account can request a full Android backup from Google Drive. Which includes app data and possibly decryption keys for the password manager. By provisioning a new Android emulator and restoring the backup, the attacker effectively clones the victim's Google Password Manager, passkeys included. Because the backup is authorized by the same account, Google's systems see it as a legitimate restore. This technique makes the attack fully automated and scalable.

Developers building authentication flows need to understand that the presence of a valid FIDO2 assertion does not, by itself, confirm the user'