The idea behind private keys is that they are private and never sent anywhere so I believe your assertion that the server knows anything about your private key is incorrect.

Here's a link to Yubico with a visual diagram of how passkeys work: https://developers.yubico.com/Passkeys/How_passkeys_work.htm...

But fundamentally it's very similar to how all public/private stuff works. You send people the public key and sign stuff with the private key.

It's very similar to how TPMs work. Discoverable keys were originally called resident keys because regular keys were almost always encrypted in the key handle and sent to the RP.

If you don't trust a system to encrypt why would you trust it to generate keys with correct random or sign without leaking key data?

The encrypted private key isn't any more likely to be a weak link than the other things a token could do wrong.

You may want to dig into the documentation a bit more.

First, ask yourself a simple question: How can a Yubikey store an unlimited number of FIDO2/U2F credentials. The official Yubikey documentation literally claims that Yubikeys can do that. Not “a lot”. Not “more than you’ll ever need”. Not 10k. Not 10M. Not 10G. Unlimited.

Gosh, maybe I should use a Yubikey for mass storage on the cheap! I wonder why nobody has done this?

Second, you’ll want to dig into what is the contents of the “key handle” that is passed from the server, through the user agent, to the key. Hint: Despite the HN hive mind, I’m not wrong.

i'm pretty sure you're wrong. or at least, you're directly contradicted by the apple docs, which say "The other key is private, and is what is needed to actually sign in. The server never learns what the private key is." https://support.apple.com/en-ca/HT213305

the basic claim about being able to store "infinite" passkeys on a USB is also directly contradicted by the yubikey docs, which say they can store 25: https://www.yubico.com/blog/a-yubico-faq-about-passkeys/

> The server has an encrypted copy of your private key, which your with token decrypts with its private key.

No, that's completely incorrect. I'm not sure where you got that impression, it would be idiotic to design an authentication protocol that way. The server has your public key, you have the private key, and that's how the server knows it's you.

This is just plain wrong. The server only ever stores your public key, private keys are stored on the clients. Everything else would defeat the entire purpose.

No it is technically correct for nondiscoverable mode. Naturally there should be low value in breaking the opacity of the stored key as it should be a private key only used with the server that holds it.

Not sure why reality is so controversial, here are references for anyone who wants to know how a (standard) unlimited fido hardware token works:

https://security.stackexchange.com/questions/237271/where-ar...

OTOH for resident keys they usually support 50-100.

It would not defeat the entire purpose.

"non-discoverable" WebAuthn keys aren't part of "passkeys", apparently, but they locally encrypt the per-site data, including the private key, and then give that encrypted data to the server to store.

This is incorrect, according to Apple’s developer docs, which states that only the public key is sent to servers. They emphasise this as a benefit: your key can’t be leaked because servers only ever receive your public key.

The private key never leaves your device except to be encrypted and synced to your other devices using iCloud Keychain.