--- title: Passkeys aren't broken, but Google's implementation has... description: Palo Alto Networks' Unit 42 disclosed three attack techniques targeting Google Password Manager's synced passkeys on Windows, dubbed 'Pass-ta-key.' The attacks... canonical: https://daily.dev/posts/passkeys-aren-t-broken-but-google-s-implementation-has-some-serious-holes-icnf2igml twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Passkeys aren't broken, but Google's implementation has some serious holes | daily.dev og:description: Palo Alto Networks' Unit 42 disclosed three attack techniques targeting Google Password Manager's synced passkeys on Windows, dubbed 'Pass-ta-key.' The attacks... og:url: https://daily.dev/posts/passkeys-aren-t-broken-but-google-s-implementation-has-some-serious-holes-icnf2igml og:image: https://api.daily.dev/og/posts/icnf2IgML.png og:image:alt: Passkeys aren't broken, but Google's implementation has some serious holes og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Passkeys aren't broken, but Google's implementation has some serious holes **[Trends](https://daily.dev/sources/trends)** · 2 min read · 1 upvotes · 0 comments ## Summary Palo Alto Networks' Unit 42 disclosed three attack techniques targeting Google Password Manager's synced passkeys on Windows, dubbed 'Pass-ta-key.' The attacks don't break passkey cryptography but exploit implementation weaknesses: unprivileged malware can impersonate a trusted device for a valid auth assertion; 'Silver Pass-ta-key' abuses device re-onboarding to register an attacker-controlled key bypassing user verification; 'Golden Pass-ta-key' extracts the security domain secret from Chrome's process memory, decrypting all synced passkeys with no rotation or revocation mechanism. Google responded by removing the secret from FIDO logs but it remains in memory. The attacks require malware already running on the device. Recommendations for high-risk environments include enforcing server-side user verification, preferring hardware-bound keys like YubiKeys, and monitoring for suspicious authenticator registrations. ## Content The security community is doing some uncomfortable recalibrating this week. Passkeys were supposed to be the clean break from password hell, and now Unit 42 researchers are on stage at Black Hat demonstrating three attacks that can hijack passkey-protected accounts without ever touching the underlying cryptography. The attack family, called Pass-ta-key, requires malware already running on the victim's machine. That's the caveat everyone is leading with, and it's a fair one. But the details are worse than the headline suggests. The three techniques target Google Password Manager's synced passkeys on Windows: - **Pass-ta-key**: Unprivileged malware impersonates a trusted device using Chrome's device identity key, generating a valid authentication assertion with no biometrics or user interaction required. - **Silver Pass-ta-key**: Attacker registers their own user-verification key during Google's device re-onboarding flow, bypassing UV checks entirely and getting persistent, device-independent account access. - **Golden Pass-ta-key**: Extracts the security domain secret (the master key that encrypts all synced passkeys) from Chrome's process memory. No current mechanism exists to rotate or revoke it. Google removed the secret from Chrome's FIDO logs after disclosure. It's still in memory. The part generating the most confusion: people assumed passkeys live in TPMs. They mostly don't. The FIDO2 spec doesn't require hardware enclaves. Most platforms and third-party managers skip them entirely. Microsoft is nearly the only exception, with optional TPM storage for enterprise accounts. Google Password Manager syncs passkeys to the cloud, which is convenient and also, apparently, the attack surface. eBay has patched its user-verification validation flaw. The broader fix requires relying parties to properly validate UV flags server-side, and credential managers to harden device re-registration flows. Neither of those is happening automatically. The honest read here: passkeys as a standard are fine. The implementation choices around syncing, recovery flows, and optional user verification are where things get messy. "Passwordless" doesn't mean "attack surface-free" when the credential manager is doing the heavy lifting and the heavy lifting involves keys sitting in process memory. ## Questions this post answers ### What are the Pass-ta-key attacks against Google Password Manager passkeys? Pass-ta-key is a set of three attacks targeting Google's synced passkey implementation on Windows, presented at Black Hat USA. The first lets unprivileged malware get a valid authentication assertion without biometrics. The second ('Silver Pass-ta-key') registers an attacker-controlled key via the re-onboarding flow for persistent access. The third ('Golden Pass-ta-key') extracts the security domain secret from Chrome's process memory, decrypting all synced passkeys with no rotation mechanism available. _Teams shipping passkey authentication track implementation-level findings like these on daily.dev before they become your incident._ ### Can the WebAuthn passkey standard itself be broken by malware on a compromised device? No — the WebAuthn cryptographic standard itself is not broken by these attacks. All three Pass-ta-key techniques require malware already running on the victim's machine and exploit implementation choices in Google's synced passkey ecosystem, such as optional user-verification flags that relying parties skip validating and sensitive key material left in Chrome's process memory, not flaws in the underlying standard. _Developers choosing between hardware-bound and synced passkeys for privileged access find the trade-off analysis on daily.dev._ ### Is there a way to rotate or revoke the Google Password Manager security domain secret if it's compromised? No rotation or revocation mechanism currently exists for the security domain secret. This master key encrypts all synced passkeys and can be extracted from Chrome's process memory by malware. Google removed it from FIDO logs after the disclosure, but it remains in memory. An attacker who extracts it gains access to every passkey the user has synced, including future ones. _Security engineers managing credential infrastructure keep up with gaps like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 54 comments across hackernews (as of 2026-08-11). **TL;DR:** Commenters largely view these as endpoint-compromise attacks rather than fundamental passkey flaws, noting that the same access level would also expose traditional passwords — but there is genuine concern about specific implementation gaps like missing UV flag validation and the inability to rotate the security domain secret. **Sentiment:** 15% positive · 45% mixed · 40% skeptical **The case for** - Responsible disclosure of real implementation gaps (missing attestation validation, no SDS rotation) that Google can and should fix. - Passkeys remain at least as secure as passwords in a local-compromise scenario, since malware with this access can harvest plaintext passwords even more trivially. - Hardware-backed secure enclaves (e.g., iPhone security coprocessor) show the architecture can in principle protect credentials even on a compromised OS. **The pushback** - The security domain secret (SDS) master key has no rotation or revocation mechanism, meaning a one-time extraction grants permanent access to all synced passkeys. - Relying parties commonly skip strict UV flag validation, allowing the Silver Pass-ta-key attack to register attacker-controlled keys without user verification. - Passkeys conflate authentication and credential storage in a way that makes a single vault compromise more catastrophic than a traditional password + separate 2FA setup. - There is still no widely supported, standardized way to export or back up passkeys offline, leaving users dependent on vendor sync ecosystems. - TPM authorization has no concept of per-process or per-user identity, so an unprivileged process can abuse the same TPM context as a privileged one like Chrome. **By community** - hackernews (mixed): Most commenters agree these are endpoint-malware-level attacks that don't uniquely undermine passkeys, but acknowledge the missing UV validation and non-rotatable SDS are real, fixable gaps worth disclosing. **Hottest debate:** Whether a compromised endpoint is already 'game over' and these findings are therefore unremarkable, or whether passkeys were supposed to offer hardware-backed protection even against local malware and thus the implementation failures are genuinely novel and serious. **Open questions** - Is there a standardized, cross-platform mechanism to export or back up passkeys offline without relying on a vendor's sync ecosystem? - Why does Chrome's implementation allow sensitive key material (SDS) to reach process memory rather than keeping it exclusively in hardware? - Can the TPM spec be extended to support per-process or per-user identity so that unprivileged processes cannot abuse keys sealed for a specific application? - Will Google provide a way to rotate or revoke the security domain secret after it has potentially been extracted? **Highlights** > These are endpoint malware attacks, not attacks on Passkeys per se. This is already a game-over position for an attacker to be in. > — [tptacek on hackernews · 1 comments](https://news.ycombinator.com/item?id=49177076) > This is someone related to a major TPM pet peeve of mine: the TPM only really cares about global device state and has no concept that a device may be a multi-user system, have multiple processes with different security levels, have multiple tenants, etc. For example, it really ought to be possible to seal a secret such that it can only be unsealed if PCRs have certain values (the usual TPM thing) and the requester of the unseal operation is tagged by the OS (software TCB) as having a certain identity. The latter part is entirely missing from the TPM spec. (The identity could be a hash of the process, just a UUID, or just about anything else as long as it was reasonably well associated with the process in question. Obviously there are subtleties here.) If the TPM worked the way I wanted, an unprivileged process running alongside Chrome would be completely unable to use the TPM to pretend to be Chrome. > — [amluto on hackernews · 2 comments](https://news.ycombinator.com/item?id=49177244) > > And if you get access to the vault, then you get everything. OK. And if you get access to a synced traditional password vault, then you get everything. No? It’s why 2FA exists. I have an email with password of 5 characters only and the password leaked decade ago, never changed it and no one accessed it because it has 2fa. I can share my whole password vault and I would not care about it because it’s useless without 2fa. Not the case with passkey, glad I never set it up on any of my accounts, pass+mfa is good for 99% of accounts (not sms obviously), rest are public private keys. > — [tamimio on hackernews](https://news.ycombinator.com/item?id=49177353) > It kinda is. If they use Chrome and it's cloud backed password manager, odds are they use GMail. That plus full access to a trusted device (which you have in this scenario) allows you to change their Google account password. Boom, full persistence. I can think of at least a dozen easier ways to do nefarious things with this level of access that are at least that simple. As an example, faking user attribution would be trivial. How could Google patch this? If the client is compromised and the attacker can manipulate the local TPM or it's equivalent there's no defense. > — [colemannugent on hackernews](https://news.ycombinator.com/item?id=49177039) > The right questions. The ability to set up an alternate key in advance is functionally similar to being able to make a backup. If I had my 'druthers: 1. You can register multiple keys, such as for different devices. Like 5-10, not two. 2. There are two categories of keys: "Regular" and "Backup/Recovery". 3. Attempting to use a Backup Recovery key prompts to user to confirm that they want to discard all regular keys and promote the backup key(s) to the new regular. In this way, a compromised backup key can't be used secretively. > — [Terr\_ on hackernews · 1 comments](https://news.ycombinator.com/item?id=49177113) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49176644) · 32 points · 54 comments - [hackernews](https://news.ycombinator.com/item?id=49155079) · 1 points · 0 comments --- Tags: [#authentication](https://daily.dev/tags/authentication), [#malware](https://daily.dev/tags/malware), [#passkeys](https://daily.dev/tags/passkeys) [View this post on daily.dev](https://daily.dev/posts/passkeys-aren-t-broken-but-google-s-implementation-has-some-serious-holes-icnf2igml) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Passkeys aren't broken, but Google's implementation has some serious holes","url":"https://daily.dev/posts/passkeys-aren-t-broken-but-google-s-implementation-has-some-serious-holes-icnf2igml","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/passkeys-aren-t-broken-but-google-s-implementation-has-some-serious-holes-icnf2igml"},"datePublished":"2026-08-06T07:48:19.666Z","dateModified":"2026-08-11T13:10:19.101Z","description":"Palo Alto Networks' Unit 42 disclosed three attack techniques targeting Google Password Manager's synced passkeys on Windows, dubbed 'Pass-ta-key.' The attacks...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/30a6a05c1dc1efb5f3f9650a7e52d614?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/30a6a05c1dc1efb5f3f9650a7e52d614?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Trends","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Trends","logo":"https://media.daily.dev/image/upload/s--ZfSp3asX--/f_auto,q_auto/v1780996004/logos/trends?_a=BAMAMiWQ0","url":"https://daily.dev/sources/trends"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/passkeys-aren-t-broken-but-google-s-implementation-has-some-serious-holes-icnf2igml","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"authentication,malware,passkeys","timeRequired":"PT2M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Trends","item":"https://daily.dev/sources/trends"},{"@type":"ListItem","position":3,"name":"Passkeys aren't broken, but Google's implementation has some serious holes"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/passkeys-aren-t-broken-but-google-s-implementation-has-some-serious-holes-icnf2igml#faq","mainEntity":[{"@type":"Question","name":"What are the Pass-ta-key attacks against Google Password Manager passkeys?","acceptedAnswer":{"@type":"Answer","text":"Pass-ta-key is a set of three attacks targeting Google's synced passkey implementation on Windows, presented at Black Hat USA. The first lets unprivileged malware get a valid authentication assertion without biometrics. The second ('Silver Pass-ta-key') registers an attacker-controlled key via the re-onboarding flow for persistent access. The third ('Golden Pass-ta-key') extracts the security domain secret from Chrome's process memory, decrypting all synced passkeys with no rotation mechanism available. Teams shipping passkey authentication track implementation-level findings like these on daily.dev before they become your incident."}},{"@type":"Question","name":"Can the WebAuthn passkey standard itself be broken by malware on a compromised device?","acceptedAnswer":{"@type":"Answer","text":"No — the WebAuthn cryptographic standard itself is not broken by these attacks. All three Pass-ta-key techniques require malware already running on the victim's machine and exploit implementation choices in Google's synced passkey ecosystem, such as optional user-verification flags that relying parties skip validating and sensitive key material left in Chrome's process memory, not flaws in the underlying standard. Developers choosing between hardware-bound and synced passkeys for privileged access find the trade-off analysis on daily.dev."}},{"@type":"Question","name":"Is there a way to rotate or revoke the Google Password Manager security domain secret if it's compromised?","acceptedAnswer":{"@type":"Answer","text":"No rotation or revocation mechanism currently exists for the security domain secret. This master key encrypts all synced passkeys and can be extracted from Chrome's process memory by malware. Google removed it from FIDO logs after the disclosure, but it remains in memory. An attacker who extracts it gains access to every passkey the user has synced, including future ones. Security engineers managing credential infrastructure keep up with gaps like this on daily.dev."}}]} ```