5 ms·

PassSeeds – hijacking Passkeys to unlock new cryptographic use cases

58 points by csuwldcat 9mo ago

csuwldcat 9mo ago
Passkeys can be hijacked to serve as cryptographic seed material that is securely synced across all of a user’s devices, enabling the generation of a wide range of cryptographic keys. This allows Passkeys to power use cases far beyond what they have traditionally been constrained to. I’ve been calling this mechanism PassSeeds. I’ll leave the details to the blog post, but here’s a short list of what PassSeeds enable: - Need a user-custodied BLS12-381 key to engage in more advanced ZKP Verifiable Credential / proofing flows? Say less, you're covered. - Want to create a petty cash Web wallet for Bitcoin transactions that relies on a secp256k1 key? Ask and ye shall receive. - How about keys for decentralized social media identifiers and post signing that are of a type other than P-256? No problem, I got you!
- phillipseamore 9mo ago
  Why use the word "hijacked" and not repurposing, extending or adapting? I'd even prefer leveraging.
  - witte 9mo ago
    [dead]
  - csuwldcat 9mo ago
    Just sounded cooler , and I was on the team that worked on Passkeys at Microsoft, so I wanted to poke them a bit (in a friendly way).
    - gcr 9mo ago
      To me, “hijacking” a passkey sounds like credential disclosure, which is quite worrying for a core team member to talk about. I know what you mean, but it’s probably the wrong term to be using if we want to emphasize that passkeys cannot be stolen.
  - fladrif 9mo ago
    I completely agree, I spent half the post confused about what exploits they were taking advantage of, and why I _shouldn't_ use passkeys.
  - gurjeet 9mo ago
    +1. I bet it's because of this confusing verbiage, the AI also got the gist of the article wrong, and lead me to believe that this article shows "post-hoc exploit" , when in fact there's no mention of the word 'exploit' in the article. See the screenshot linked below [1]. On a tangent, in the process I learnt that Firefox (at least on desktop) now has an "AI preview" feature where if you long-press on a URL, it brings up the pop-up. The first time, it notifies that the "AI" processing is local-only to preserve privacy. [1]: Screenshot 2026-01-06 at 6.33.27 PM.png https://drive.google.com/file/d/15z--Oimct30QLuxR03nxMz9H_3LWTGg9 https://drive.google.com/file/d/15z--Oimct30QLuxR03nxMz9H_3L...
- arjvik 9mo ago
  I don’t understand why you want to enforce only using the public key instead of private key - while I believe you that as of now browsers do not disclose the public key anywhere, I’d also suspect that this is far more likely to be violated and accidentally disclosed by a bug than the private key, which theoretically cannot ever leave the TPM. Would KDF(deterministic_sign(“well-known message”)) not also provide valid entropy? Is it just impossible to force a nonce for a deterministic signature?
- MattPalmer1086 9mo ago
  What stops anyone else doing the ECDSA public key recovery hack by signing two identical messages and getting the public key, i.e. the thing you are using as a cryptographic seed? In general, using a key for a purpose it was not designed for gets you into trouble. Treating a public key as private key seed material is almost certainly going to be a problem. Systems are just not designed to keep public keys secret, even if webauth does.
  - csuwldcat 9mo ago
    That would either mean you have arbitrary, malicious code executing in the bound origin (the origin was hacked and shipped malicious code), or you allowed random callers externally to take signatures out of the boundary - don't do either of these things, they are verboten. The whole point is that for the passkey you use as a PassSeed, you never do any signing other than locally for ECDSA recovery.
    - MattPalmer1086 9mo ago
      It seems malicious code on the phone can get the public key and thus derive the secret keys. This is weaker protection than PassKeys provide (would have to crack the hardware, not just software).
deleted 9mo ago
[deleted]
josephcsible 9mo ago
How is this any better than just storing the value in a password manager, or in YubiKey's "Static Password" mode? Also, the "ECDSA Public Key Recovery" picture makes me suspect this is AI slop.
- csuwldcat 9mo ago
  How it's better: automatically synced across all a user's devices, not subject to manual interactions with input fields (you can't programmatically request/regen passwords the same way you can with this). I did use AI for the ECDSA public key recovery diagram, because I wasn't about to spend hours hand rolling that in Lunacy. It's correct in broad strokes, and anyone who wants to understand it more deeply can just look at the code, imo.
  - sandeepkd 9mo ago
    IMO automatic sync is a mess with the passkeys, it just muddies the whole guarantees around security based on possession, its not available unless you are signed in on the platform (eg. apple account) making the behavior inconsistent
- sandeepkd 9mo ago
  I think if you are doing it in the browser then you bind the flow to the request origin making it phishing resistant compared to a static, origin agnostic storage
notorious_pgb 9mo ago
Interesting, but the PRF / LargeBlob extensions already enable just such functionality (and more) without relying on the secrecy of a public key. Why not just use those? Edit: that's what I get for not reading far enough -- the article addresses this, though I would quibble with the confident assertion that the extensions are not available in major browsers, given I worked for a startup literal years ago which built major functionality on top of these extensions, which were available in (at least) all relevant mobile browsers.
- deleted 9mo ago
  [deleted]
- csuwldcat 9mo ago
  I addressed this in the post - neither is available across all major browsers: https://backalleycoder.com/posts/passseeds-an-experiment-in-hijacking-passkeys-to-unlock-cryptographic-use-cases/#why-not-use-the-webauthns-prf-or-large-blob-features https://backalleycoder.com/posts/passseeds-an-experiment-in-... Ironically, you could make a pollyfill for the PRF functionality with this.
  - csuwldcat 9mo ago
    Saw your post above - I didn't "assert falsehoods", both are missing major browser support: https://caniuse.com/mdn-api_credentialscontainer_get_publickey_option_extensions_prf https://caniuse.com/mdn-api_credentialscontainer_get_publick... https://caniuse.com/mdn-api_credentialscontainer_get_publickey_option_extensions_largeblob https://caniuse.com/mdn-api_credentialscontainer_get_publick...
    - notorious_pgb 9mo ago
      You're right and I was misremembering (we had only developed against modern mobile browsers), though I am 100% certain we made use of these extensions on iOS Safari, so I honestly don't believe caniuse when they assert that it supports _neither_ extension. Per my recollection, iOS Safari supported the large blob extension quite early on. Apologies for the brash statement earlier; that was wrong of me.
blibble 9mo ago
it seems foolish to build a system that relies on the token to essentially be a secure way to store a public key when the entire point of the token is to guard the private key, and make the public key accessible
- csuwldcat 9mo ago
  The interesting thing about Passkeys is that they are only ever output in the client create() call, and the platform does not retain them for disclosure after that, so if you don't send them out of the origin boundary, they are treated like a virtually secret value by the platform. It's ironic, because the WebAuthn/Passkey authors (who I know some of) explicitly treat the public key as a sensitive value, and built system assumptions around that, which is what makes this possible. It's a rather gross hack, can't deny it that, but there are a group of use cases for which it is a better fit than any of the far more ugly flows many non-P-256 self-custodied key use cases are accomplished with today.
  - blibble 9mo ago
    > they are treated like a virtually secret value by the platform "virtually" is the problem for webauthn the public key isn't revealed to everyone for privacy reasons, not cryptographic reasons the webauthn API is also only part of the cryptosystem the platform authenticator (yubikey, windows hello, password manager, whatever) may have an API to list stored public keys without any authentication at all because they were never intended to be protected
    - csuwldcat 9mo ago
      It's a deliberate architectural decision that passkey authenticators not allow any retrieval or enumeration of key pairs - they don't even have internal APIs for it. This holds true for all known implementations, as it is a core principle of the system design.
      - blibble 9mo ago
rsoury 9mo ago
If a compromised browser extension intercepts the public key, there's an attack vector.
- csuwldcat 9mo ago
  Yes, this is true, however, that means an external actor is able to execute arbitrary code in your origin, so they could also trick the user into signing malicious payloads with even the native passkey itself. There's more downside to exfiltration here, but having arbitrary code from an external party executing in your page is a more general cause for concern you'd need to mitigate regardless.
coppsilgold 9mo ago
Ultimately what he is suggesting to do is to bind a string of entropy to a website through facilitation of the browser and a Passkey. A cryptographic seed is one of the most sensitive things. And here you choose to expose it to a website (even though it was specifically generated for that website). This is not something you do for authentication. The only reason to do this is to have javascript/wasm on a website perform sensitive cryptographic operations for you. You should never be doing this. Applications such as password managers can already integrate entropy from a passkey to encrypt their databases using the Challenge-Response protocol: https://docs.yubico.com/yesdk/users-manual/application-otp/challenge-response.html https://docs.yubico.com/yesdk/users-manual/application-otp/c...
- csuwldcat 9mo ago
  You can run the PassSeed code/mechanism on your own domain or localhost to ensure it's not subject to malicious host exfiltratuon. I agree that one should only trust a foreign host with low-security uses under this scheme.
a022311 9mo ago
It's interesting to see another use case for passkeys. The demo doesn't work with Bitwarden though :(
arianvanp 9mo ago
Fails with Error: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations-client https://www.w3.org/TR/webauthn-2/#sctn-privacy-consideration.... On Android
- csuwldcat 9mo ago
  Hmm, can you provide further details? I'm using it on Android in Chrome and Brave, and it works fine.

58 points by csuwldcat 9mo ago

Passkeys can be hijacked to serve as cryptographic seed material that is securely synced across all of a user’s devices, enabling the generation of a wide range of cryptographic keys. This allows Passkeys to power use cases far beyond what they have traditionally been constrained to. I’ve been calling this mechanism PassSeeds. I’ll leave the details to the blog post, but here’s a short list of what PassSeeds enable: - Need a user-custodied BLS12-381 key to engage in more advanced ZKP Verifiable Credential / proofing flows? Say less, you're covered. - Want to create a petty cash Web wallet for Bitcoin transactions that relies on a secp256k1 key? Ask and ye shall receive. - How about keys for decentralized social media identifiers and post signing that are of a type other than P-256? No problem, I got you!

phillipseamore 9mo ago
Why use the word "hijacked" and not repurposing, extending or adapting? I'd even prefer leveraging.
- witte 9mo ago
  [dead]
- csuwldcat 9mo ago
  Just sounded cooler , and I was on the team that worked on Passkeys at Microsoft, so I wanted to poke them a bit (in a friendly way).
  - gcr 9mo ago
    To me, “hijacking” a passkey sounds like credential disclosure, which is quite worrying for a core team member to talk about. I know what you mean, but it’s probably the wrong term to be using if we want to emphasize that passkeys cannot be stolen.
- fladrif 9mo ago
  I completely agree, I spent half the post confused about what exploits they were taking advantage of, and why I _shouldn't_ use passkeys.
- gurjeet 9mo ago
  +1. I bet it's because of this confusing verbiage, the AI also got the gist of the article wrong, and lead me to believe that this article shows "post-hoc exploit" , when in fact there's no mention of the word 'exploit' in the article. See the screenshot linked below [1]. On a tangent, in the process I learnt that Firefox (at least on desktop) now has an "AI preview" feature where if you long-press on a URL, it brings up the pop-up. The first time, it notifies that the "AI" processing is local-only to preserve privacy. [1]: Screenshot 2026-01-06 at 6.33.27 PM.png https://drive.google.com/file/d/15z--Oimct30QLuxR03nxMz9H_3LWTGg9 https://drive.google.com/file/d/15z--Oimct30QLuxR03nxMz9H_3L...
arjvik 9mo ago
I don’t understand why you want to enforce only using the public key instead of private key - while I believe you that as of now browsers do not disclose the public key anywhere, I’d also suspect that this is far more likely to be violated and accidentally disclosed by a bug than the private key, which theoretically cannot ever leave the TPM. Would KDF(deterministic_sign(“well-known message”)) not also provide valid entropy? Is it just impossible to force a nonce for a deterministic signature?
MattPalmer1086 9mo ago
What stops anyone else doing the ECDSA public key recovery hack by signing two identical messages and getting the public key, i.e. the thing you are using as a cryptographic seed? In general, using a key for a purpose it was not designed for gets you into trouble. Treating a public key as private key seed material is almost certainly going to be a problem. Systems are just not designed to keep public keys secret, even if webauth does.
- csuwldcat 9mo ago
  That would either mean you have arbitrary, malicious code executing in the bound origin (the origin was hacked and shipped malicious code), or you allowed random callers externally to take signatures out of the boundary - don't do either of these things, they are verboten. The whole point is that for the passkey you use as a PassSeed, you never do any signing other than locally for ECDSA recovery.
  - MattPalmer1086 9mo ago
    It seems malicious code on the phone can get the public key and thus derive the secret keys. This is weaker protection than PassKeys provide (would have to crack the hardware, not just software).

deleted 9mo ago

[deleted]

josephcsible 9mo ago

How is this any better than just storing the value in a password manager, or in YubiKey's "Static Password" mode? Also, the "ECDSA Public Key Recovery" picture makes me suspect this is AI slop.

csuwldcat 9mo ago
How it's better: automatically synced across all a user's devices, not subject to manual interactions with input fields (you can't programmatically request/regen passwords the same way you can with this). I did use AI for the ECDSA public key recovery diagram, because I wasn't about to spend hours hand rolling that in Lunacy. It's correct in broad strokes, and anyone who wants to understand it more deeply can just look at the code, imo.
- sandeepkd 9mo ago
  IMO automatic sync is a mess with the passkeys, it just muddies the whole guarantees around security based on possession, its not available unless you are signed in on the platform (eg. apple account) making the behavior inconsistent
sandeepkd 9mo ago
I think if you are doing it in the browser then you bind the flow to the request origin making it phishing resistant compared to a static, origin agnostic storage

notorious_pgb 9mo ago

Interesting, but the PRF / LargeBlob extensions already enable just such functionality (and more) without relying on the secrecy of a public key. Why not just use those? Edit: that's what I get for not reading far enough -- the article addresses this, though I would quibble with the confident assertion that the extensions are not available in major browsers, given I worked for a startup literal years ago which built major functionality on top of these extensions, which were available in (at least) all relevant mobile browsers.

deleted 9mo ago
[deleted]
csuwldcat 9mo ago
I addressed this in the post - neither is available across all major browsers: https://backalleycoder.com/posts/passseeds-an-experiment-in-hijacking-passkeys-to-unlock-cryptographic-use-cases/#why-not-use-the-webauthns-prf-or-large-blob-features https://backalleycoder.com/posts/passseeds-an-experiment-in-... Ironically, you could make a pollyfill for the PRF functionality with this.
- csuwldcat 9mo ago
  Saw your post above - I didn't "assert falsehoods", both are missing major browser support: https://caniuse.com/mdn-api_credentialscontainer_get_publickey_option_extensions_prf https://caniuse.com/mdn-api_credentialscontainer_get_publick... https://caniuse.com/mdn-api_credentialscontainer_get_publickey_option_extensions_largeblob https://caniuse.com/mdn-api_credentialscontainer_get_publick...
  - notorious_pgb 9mo ago
    You're right and I was misremembering (we had only developed against modern mobile browsers), though I am 100% certain we made use of these extensions on iOS Safari, so I honestly don't believe caniuse when they assert that it supports _neither_ extension. Per my recollection, iOS Safari supported the large blob extension quite early on. Apologies for the brash statement earlier; that was wrong of me.

blibble 9mo ago

it seems foolish to build a system that relies on the token to essentially be a secure way to store a public key when the entire point of the token is to guard the private key, and make the public key accessible

csuwldcat 9mo ago
The interesting thing about Passkeys is that they are only ever output in the client create() call, and the platform does not retain them for disclosure after that, so if you don't send them out of the origin boundary, they are treated like a virtually secret value by the platform. It's ironic, because the WebAuthn/Passkey authors (who I know some of) explicitly treat the public key as a sensitive value, and built system assumptions around that, which is what makes this possible. It's a rather gross hack, can't deny it that, but there are a group of use cases for which it is a better fit than any of the far more ugly flows many non-P-256 self-custodied key use cases are accomplished with today.
- blibble 9mo ago
  > they are treated like a virtually secret value by the platform "virtually" is the problem for webauthn the public key isn't revealed to everyone for privacy reasons, not cryptographic reasons the webauthn API is also only part of the cryptosystem the platform authenticator (yubikey, windows hello, password manager, whatever) may have an API to list stored public keys without any authentication at all because they were never intended to be protected
  - csuwldcat 9mo ago
    It's a deliberate architectural decision that passkey authenticators not allow any retrieval or enumeration of key pairs - they don't even have internal APIs for it. This holds true for all known implementations, as it is a core principle of the system design.
    - blibble 9mo ago

rsoury 9mo ago

If a compromised browser extension intercepts the public key, there's an attack vector.

csuwldcat 9mo ago
Yes, this is true, however, that means an external actor is able to execute arbitrary code in your origin, so they could also trick the user into signing malicious payloads with even the native passkey itself. There's more downside to exfiltration here, but having arbitrary code from an external party executing in your page is a more general cause for concern you'd need to mitigate regardless.

coppsilgold 9mo ago

Ultimately what he is suggesting to do is to bind a string of entropy to a website through facilitation of the browser and a Passkey. A cryptographic seed is one of the most sensitive things. And here you choose to expose it to a website (even though it was specifically generated for that website). This is not something you do for authentication. The only reason to do this is to have javascript/wasm on a website perform sensitive cryptographic operations for you. You should never be doing this. Applications such as password managers can already integrate entropy from a passkey to encrypt their databases using the Challenge-Response protocol: https://docs.yubico.com/yesdk/users-manual/application-otp/challenge-response.html https://docs.yubico.com/yesdk/users-manual/application-otp/c...

csuwldcat 9mo ago
You can run the PassSeed code/mechanism on your own domain or localhost to ensure it's not subject to malicious host exfiltratuon. I agree that one should only trust a foreign host with low-security uses under this scheme.

a022311 9mo ago

It's interesting to see another use case for passkeys. The demo doesn't work with Bitwarden though :(

arianvanp 9mo ago

Fails with Error: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations-client https://www.w3.org/TR/webauthn-2/#sctn-privacy-consideration.... On Android

csuwldcat 9mo ago
Hmm, can you provide further details? I'm using it on Android in Chrome and Brave, and it works fine.