Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PassSeeds – hijacking Passkeys to unlock new cryptographic use cases

backalleycoder.com

Post reply on HN
Print view View original

11–20 of 45 posts

Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases

#11

Post by csuwldcat »

notorious_pgb wrote: post #9

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…

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.

Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases

#12

Post by csuwldcat »

csuwldcat wrote: post #11
notorious_pgb wrote: post #9

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…

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.

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...

Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases

#13

Post by notorious_pgb »

csuwldcat wrote: post #11
notorious_pgb wrote: post #9

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…

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.

Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases

#14

Post by gcr »

csuwldcat wrote: post #6
phillipseamore wrote: post #3

Earlier quoted context omitted.

Why use the word "hijacked" and not repurposing, extending or adapting? I'd even prefer leveraging.

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.

Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases

#16

Post by notorious_pgb »

csuwldcat wrote: post #12
csuwldcat wrote: post #11

Earlier quoted context omitted.

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.

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.

Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases

#17

Post by csuwldcat »

blibble wrote: post #15

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.

Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases

#18

Post by fladrif »

phillipseamore wrote: post #3
csuwldcat wrote: post #2

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:…

Why use the word "hijacked" and not repurposing, extending or adapting? I'd even prefer leveraging.

I completely agree, I spent half the post confused about what exploits they were taking advantage of, and why I _shouldn't_ use passkeys.

Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases

#19

Post by blibble »

csuwldcat wrote: post #17
blibble wrote: post #15

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 sy…

> 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

Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases

#20

Post by gurjeet »

phillipseamore wrote: post #3
csuwldcat wrote: post #2

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:…

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...

Post reply on HN