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!

▲

arjvik 2 days ago | parent | next [-]

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?

▲

phillipseamore 2 days ago | parent | prev | next [-]

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

▲

gurjeet 2 days ago | parent | next [-]

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

▲

fladrif 2 days ago | parent | prev | next [-]

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

▲

csuwldcat 2 days ago | parent | prev | next [-]

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 2 days ago \| parent [-]
		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.

▲

witte 2 days ago | parent | prev [-]

[dead]

▲

MattPalmer1086 2 days ago | parent | prev [-]

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 2 days ago | parent [-]

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 2 days ago \| parent [-]
		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).