Synced Passkeys Are Just Passwords With Better Marketing

TLDR: Synced passkeys, often touted as the ultimate defense against phishing, are fundamentally flawed when stored in browser-based password managers. By performing a man-in-the-middle attack on the browser's sync flow, an attacker can exfiltrate private keys and gain full access to a victim's accounts. This research demonstrates that the convenience of syncing credentials across devices introduces a single point of failure that bypasses the security benefits of hardware-bound authentication.

The industry has spent years pushing passkeys as the silver bullet for identification and authentication failures. The narrative is simple: hardware-bound, phishing-resistant, and unphishable. But as researchers recently demonstrated at DEF CON, the implementation reality is a massive step backward for anyone who values actual security over user convenience. When you sync your passkeys across your devices via a browser-based password manager, you are not using a secure, hardware-bound credential. You are using a password that is just easier to steal.

The Mechanics of the Sync Trap

The core issue lies in the distinction between device-bound passkeys and synced passkeys. A true FIDO2/WebAuthn implementation generates a private key on a secure element that never leaves the device. If you lose your laptop, you lose that specific key. That is the point. It is a physical "something you have" factor.

Synced passkeys, however, are designed to be portable. When you enable sync in Chrome or Bitwarden, the browser or manager takes that private key and encrypts it, then pushes it to the cloud so it can be pulled down by your other devices. The problem is that the encryption key for this sync data is often derived from the user's master password or the browser's local state.

If an attacker can phish the user's credentials—or simply compromise the local machine—they can intercept the sync flow. The research presented at DEF CON showed a proof-of-concept where an attacker uses a Flask application to emulate a legitimate login page. By injecting keystrokes into the browser, the attacker can trigger the sync process. Once the victim logs in, the attacker waits for the passkeys to sync, then exports the entire vault.

Reproducing the Exfiltration

The technical barrier to entry for this attack is surprisingly low. Because the browser handles the decryption of these keys to make them available for authentication, the keys must exist in a decrypted state in memory or on disk at some point. On Chrome, these are stored in a LevelDB database.

An attacker with local access or a successful phishing session can target these files directly. The following command structure illustrates how one might begin to interact with the stored data:

# Locate the sync data directory
cd ~/.config/google-chrome/Default/Sync\ Data/LevelDB/

# Extract the encrypted blobs
# The attacker then uses the master password or local machine key 
# to decrypt the passkey material.

Once the attacker has the private key, they can import it into their own instance of Bitwarden or another password manager. At that point, the "phishing-resistant" nature of the passkey is irrelevant. The attacker is now the user. They can authenticate to any service that the victim has registered with that passkey, completely bypassing any secondary factors that might have been tied to the original device.

Why This Matters for Pentesters

During a red team engagement, you are likely looking for the path of least resistance. Historically, that meant dumping LSASS or looking for cleartext credentials in configuration files. Now, you should be looking for synced passkeys. If you can compromise a developer's machine, you don't need to crack their password hash. You just need to export their synced passkey vault.

The impact is total account takeover. Because many services disable password-only logins once a passkey is enrolled, the passkey becomes the primary and often only way to access the account. If you steal the passkey, you own the account, and the victim has no way to "reset" the passkey without your cooperation.

The Defensive Reality

Defenders need to stop treating "synced" as a synonym for "secure." If you are managing an enterprise environment, you must enforce the use of hardware-bound security keys for sensitive accounts. Do not allow users to sync corporate passkeys to personal browser accounts.

The WebAuthn specification is robust, but the implementation choices made by browser vendors are prioritizing user experience over security. As a researcher or pentester, your focus should be on identifying where these keys are stored and how they are being moved. If you are building a security program, assume that any credential that can be synced can be stolen.

We have traded the friction of a physical security key for the convenience of a synced vault, and in doing so, we have reintroduced the exact class of vulnerabilities that FIDO2 was supposed to eliminate. The next time you see a "secure" login prompt, ask yourself where that private key actually lives. If it’s in the cloud, it’s already compromised.