--- title: Pass the Passkey: A Novel Attack Surface in Passwordless... description: Security researchers from Unit 42 disclose three novel attack classes against Google's synced passkey ecosystem, collectively dubbed 'Pass-ta-key' attacks. The... canonical: https://daily.dev/posts/pass-the-passkey-a-novel-attack-surface-in-passwordless-authentication-0tej0udps twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Pass the Passkey: A Novel Attack Surface in Passwordless Authentication | daily.dev og:description: Security researchers from Unit 42 disclose three novel attack classes against Google's synced passkey ecosystem, collectively dubbed 'Pass-ta-key' attacks. The... og:url: https://daily.dev/posts/pass-the-passkey-a-novel-attack-surface-in-passwordless-authentication-0tej0udps og:image: https://api.daily.dev/og/posts/0teJ0udPS.png og:image:alt: Pass the Passkey: A Novel Attack Surface in Passwordless Authentication 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. # Pass the Passkey: A Novel Attack Surface in Passwordless Authentication **[Unit 42](https://daily.dev/sources/unit42)** · 23 min read · 0 upvotes · 0 comments ## Summary Security researchers from Unit 42 disclose three novel attack classes against Google's synced passkey ecosystem, collectively dubbed 'Pass-ta-key' attacks. The attacks demonstrate how unprivileged malware on a compromised endpoint can exploit implementation gaps to take over passkey-protected accounts without user interaction. The Pass-ta-key attack abuses Chrome's device identity key to silently authenticate as the victim. The Silver Pass-ta-key attack registers an attacker-controlled UV key during the device re-onboarding flow, bypassing user verification entirely and enabling persistent, device-independent account access. The Golden Pass-ta-key attack extracts the security domain secret (SDS) master key from Chrome's process memory, allowing decryption of all synced passkey private keys — with no current mechanism to rotate or revoke the SDS. Key mitigations include enforcing strict UV flag validation on relying parties, validating device key attestation during registration, hardening recovery flows, and preventing sensitive key material from reaching client memory. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 2 discussions and 54 comments across hackernews (as of 2026-08-08). **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 ## Similar posts on daily.dev - [39 New Methods That Compromise Passkey Authentication](https://daily.dev/posts/39-new-methods-that-compromise-passkey-authentication-z1hysnxm6) · BleepingComputer · 1 upvotes · 0 comments - [How Attackers Bypass Synced Passkeys](https://daily.dev/posts/how-attackers-bypass-synced-passkeys-fc1em5n6y) · The Hacker News · 0 upvotes · 0 comments - [Passkeys are a trap. Do not use them](https://daily.dev/posts/passkeys-are-a-trap-do-not-use-them-baofhwveg) · Hacker News · 1 upvotes · 0 comments - [What Are Passkeys and How Do They Work?](https://daily.dev/posts/what-are-passkeys-and-how-do-they-work--eywgznf7x) · Security Boulevard · 2 upvotes · 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/pass-the-passkey-a-novel-attack-surface-in-passwordless-authentication-0tej0udps) ```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":"Pass the Passkey: A Novel Attack Surface in Passwordless Authentication","url":"https://daily.dev/posts/pass-the-passkey-a-novel-attack-surface-in-passwordless-authentication-0tej0udps","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/pass-the-passkey-a-novel-attack-surface-in-passwordless-authentication-0tej0udps"},"datePublished":"2026-08-03T10:04:02.993Z","dateModified":"2026-08-08T06:48:00.617Z","description":"Security researchers from Unit 42 disclose three novel attack classes against Google's synced passkey ecosystem, collectively dubbed 'Pass-ta-key' attacks. The...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/9b5daafc79d979a53d8f918f5aa46f54?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/9b5daafc79d979a53d8f918f5aa46f54?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Unit 42","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":"Unit 42","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/5b55ca8d2ae04181939041fbc9d78160","url":"https://daily.dev/sources/unit42"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/pass-the-passkey-a-novel-attack-surface-in-passwordless-authentication-0tej0udps","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"authentication,malware,passkeys","timeRequired":"PT23M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Unit 42","item":"https://daily.dev/sources/unit42"},{"@type":"ListItem","position":3,"name":"Pass the Passkey: A Novel Attack Surface in Passwordless Authentication"}]} ```