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.
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.
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!
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?
+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.
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.
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.
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.
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).
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.
> 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
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.
The underlying CTAP implementations are only used by the platform to facilitate core activities, they are not used to expose key pairs to external parties. Please link to where any API offers up public keys to external userland actors, and any use of said APIs beyond core credential management. If this is assumed insecure/exposed, it would mean the system and its guarantees cannot be trusted as advertised, given both keys are supposed to be handled as a secure, opaque bundle, disclosed to no one beyond the bound origin at create time.
> Given both keys are supposed to be handled as a secure, opaque bundle, disclosed to no one beyond the bound origin at create time.
yes, there is no way to enumerate the public key in the webauthn api, but this is a property of the webauthn api only
the passkey cryptosystem consists of more than the webauthn api
there's the platform and roaming authenticators too
and you can't ignore them because they are the part of the passkeys cryptosystem that actually store the key material
and I have shown you, it is common for the layer below webauthn to support enumeration of the resident public keys
because... it's useful!
million dollar HSMs let you enumerate & see public keys, protected Java keystores let you enumerate & see the public keys, the windows certificate manager lets you enumerate & see public keys
(because surely no-one would be daft enough to try to build a secret key scheme out of the public keys of a pair?)
There's also the specific case of synced passkeys, which aren't exposed to CTAP management APIs for external parties, only to the OS/platform itself. You seem tied to a narrative where a user can install a native app that gets permission to call core OS/platform APIs that let the app get all the public keys of passkeys on the device, but no such permissions/APIs exist for apps, and providing them would be in explicit violation of the fundamental security model. In reality, only the platform/OS and highly trusted actors/components that are already within the existing trust model have such access for internal purposes, and if that's not a safe assumption, it would have broader implications beyond this concern.
> You seem tied to a narrative where a user can install a native app that gets permission to call core OS/platform APIs that let the app get all the public keys of passkeys on the device
yes? one of the main points of passkeys is that if your device is compromised: all your accounts aren't.
with your system, they are
> In reality, only the platform/OS and highly trusted actors/components that are already within the existing trust model
no, they aren't, if they were, the HSM/secure enclave wouldn't be needed at all
I've entertained this nonsense for almost 2 hours now, I'm done
the fact is, if the public key gets out, then your system is compromised
and I have shown you most (df not all) roaming authenticators have a way to enumerate public keys
as does every software
HSM I've ever interacted with
A roaming authenticator does not have access to a CTAP mechanism to query the platform’s credential store. CTAP defines how the platform queries a roaming authenticator, in that direction. There is no CTAP command whereby an authenticator queries the platform for 'all passkeys you have' because the platform is the client in its protocol model. Platform / synced passkeys managed by the OS are not present on the roaming authenticator, so credential management APIs invoked from the roaming authenticator cannot enumerate them (it can only enumerate what it stores).
It's not just about the WebAuthn API, you're talking about passkeys as if their key bundles are freely accessible to random userland actors, which is absurd. If that were the case, many assurances the platform makes would be out the window. The reality is that you are obviously already trusting the platform, hardware, its software/firmware, and the implementation's use of core key management APIs, which it doesn't just offer up to random callers. If you think any of those components/actors are not adhering to fundamental boundaries/limitations, like exposure of sensitive credential material to random callers on the device, it's a more far reaching indictment of passkeys in general.
> If that were the case, many assurances the platform makes would be out the window. The reality is that you are obviously already trusting the platform, hardware, its software/firmware, and the implementation's use of core key management APIs, which it doesn't just offer up to random callers.
the point of the
authenticator is that you don't need need to trust the platform, the operating system the browser or anything other than the authenticator
the authenticators job is to secure the private key, but it will happily serve up the public key to "random callers"
the browser/webauthn are not special, it's just another untrusted "random caller" from the authenticator's perspective
webauthn will not allow the public key out, but the authenticator will
> If you think any of those components/actors are not adhering to fundamental boundaries/limitations, like exposure of sensitive credential material to random callers on the device, it's a more far reaching indictment of passkeys in general.
there's nothing cryptographically sensitive about the public key
No need for the "oh dear"-ing before you provide evidence. I'm not aware of any command for fetch or enumeration of public keys in CTAP (was rather confident it doesn't provide any such thing). Care to link to what you were referring to?
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.
Very fair (see my edit), though I would submit to you that this isn't a sufficient polyfill for PRF, since PRF allows for a _secondary secret_ alongside the public key, allowing the server to safely store the public key without storing the cryptographic seed material itself.
The inability to use a passkey for the purposes of both authentication and secret storage (at least, without building non-trivial additional cryptographic plumbing) seems to me a reason to just use and push for the continued adoption and acceleration of the purpose-built extensions, instead of reusing a _public_ key as private material.
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.
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.
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
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.
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
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/c...
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.
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!
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?
Why use the word "hijacked" and not repurposing, extending or adapting? I'd even prefer leveraging.
+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_3L...
I completely agree, I spent half the post confused about what exploits they were taking advantage of, and why I _shouldn't_ use passkeys.
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).
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.
[dead]
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.
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.
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).
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
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.
> 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
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.
> it's a deliberate architectural decision that passkey authenticators not allow any retrieval or enumeration of key pairs
there is no much thing as a "passkey authenticator"
there are "platform authenticator" and "roaming authenticators"
> they don't even have internal APIs for it.
CTAP has an enumerate credentials command, which returns, among other things:
> publicKey (0x08): public key of the credential in COSE_Key format
https://fidoalliance.org/specs/fido-v2.3-rd-20251023/fido-cl...
> This holds true for all known implementations, as it is a core principle of the system design.
oh dear
The underlying CTAP implementations are only used by the platform to facilitate core activities, they are not used to expose key pairs to external parties. Please link to where any API offers up public keys to external userland actors, and any use of said APIs beyond core credential management. If this is assumed insecure/exposed, it would mean the system and its guarantees cannot be trusted as advertised, given both keys are supposed to be handled as a secure, opaque bundle, disclosed to no one beyond the bound origin at create time.
> Given both keys are supposed to be handled as a secure, opaque bundle, disclosed to no one beyond the bound origin at create time.
yes, there is no way to enumerate the public key in the webauthn api, but this is a property of the webauthn api only
the passkey cryptosystem consists of more than the webauthn api
there's the platform and roaming authenticators too
and you can't ignore them because they are the part of the passkeys cryptosystem that actually store the key material
and I have shown you, it is common for the layer below webauthn to support enumeration of the resident public keys
because... it's useful!
million dollar HSMs let you enumerate & see public keys, protected Java keystores let you enumerate & see the public keys, the windows certificate manager lets you enumerate & see public keys
(because surely no-one would be daft enough to try to build a secret key scheme out of the public keys of a pair?)
There's also the specific case of synced passkeys, which aren't exposed to CTAP management APIs for external parties, only to the OS/platform itself. You seem tied to a narrative where a user can install a native app that gets permission to call core OS/platform APIs that let the app get all the public keys of passkeys on the device, but no such permissions/APIs exist for apps, and providing them would be in explicit violation of the fundamental security model. In reality, only the platform/OS and highly trusted actors/components that are already within the existing trust model have such access for internal purposes, and if that's not a safe assumption, it would have broader implications beyond this concern.
> You seem tied to a narrative where a user can install a native app that gets permission to call core OS/platform APIs that let the app get all the public keys of passkeys on the device
yes? one of the main points of passkeys is that if your device is compromised: all your accounts aren't.
with your system, they are
> In reality, only the platform/OS and highly trusted actors/components that are already within the existing trust model
no, they aren't, if they were, the HSM/secure enclave wouldn't be needed at all
I've entertained this nonsense for almost 2 hours now, I'm done
the fact is, if the public key gets out, then your system is compromised
and I have shown you most (df not all) roaming authenticators have a way to enumerate public keys
as does every software HSM I've ever interacted with
A roaming authenticator does not have access to a CTAP mechanism to query the platform’s credential store. CTAP defines how the platform queries a roaming authenticator, in that direction. There is no CTAP command whereby an authenticator queries the platform for 'all passkeys you have' because the platform is the client in its protocol model. Platform / synced passkeys managed by the OS are not present on the roaming authenticator, so credential management APIs invoked from the roaming authenticator cannot enumerate them (it can only enumerate what it stores).
It's not just about the WebAuthn API, you're talking about passkeys as if their key bundles are freely accessible to random userland actors, which is absurd. If that were the case, many assurances the platform makes would be out the window. The reality is that you are obviously already trusting the platform, hardware, its software/firmware, and the implementation's use of core key management APIs, which it doesn't just offer up to random callers. If you think any of those components/actors are not adhering to fundamental boundaries/limitations, like exposure of sensitive credential material to random callers on the device, it's a more far reaching indictment of passkeys in general.
> If that were the case, many assurances the platform makes would be out the window. The reality is that you are obviously already trusting the platform, hardware, its software/firmware, and the implementation's use of core key management APIs, which it doesn't just offer up to random callers.
the point of the authenticator is that you don't need need to trust the platform, the operating system the browser or anything other than the authenticator
the authenticators job is to secure the private key, but it will happily serve up the public key to "random callers"
the browser/webauthn are not special, it's just another untrusted "random caller" from the authenticator's perspective
webauthn will not allow the public key out, but the authenticator will
> If you think any of those components/actors are not adhering to fundamental boundaries/limitations, like exposure of sensitive credential material to random callers on the device, it's a more far reaching indictment of passkeys in general.
there's nothing cryptographically sensitive about the public key
hence the name: PUBLIC key
No need for the "oh dear"-ing before you provide evidence. I'm not aware of any command for fetch or enumeration of public keys in CTAP (was rather confident it doesn't provide any such thing). Care to link to what you were referring to?
> No need for the "oh dear"-ing before you provide evidence.
... there's a link in the comment
> I'm not aware of any command for fetch or enumeration of public keys in CTAP (was rather confident it doesn't provide any such thing).
how do you think the discoverable key credential management dialogs work?
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.
I addressed this in the post - neither is available across all major browsers: https://backalleycoder.com/posts/passseeds-an-experiment-in-...
Ironically, you could make a pollyfill for the PRF functionality with this.
Very fair (see my edit), though I would submit to you that this isn't a sufficient polyfill for PRF, since PRF allows for a _secondary secret_ alongside the public key, allowing the server to safely store the public key without storing the cryptographic seed material itself.
The inability to use a passkey for the purposes of both authentication and secret storage (at least, without building non-trivial additional cryptographic plumbing) seems to me a reason to just use and push for the continued adoption and acceleration of the purpose-built extensions, instead of reusing a _public_ key as private material.
Saw your post above - I didn't "assert falsehoods", both are missing major browser support:
https://caniuse.com/mdn-api_credentialscontainer_get_publick...
https://caniuse.com/mdn-api_credentialscontainer_get_publick...
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.
It's interesting to see another use case for passkeys. The demo doesn't work with Bitwarden though :(
Fails with
Error: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-consideration....
On Android
Hmm, can you provide further details? I'm using it on Android in Chrome and Brave, and it works fine.
If a compromised browser extension intercepts the public key, there's an attack vector.
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.
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.
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
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.
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