> Safe from server leaks. Because servers only keep public keys, servers are less valuable targets for hackers
That’s not quite true, though. What is true is that the server does not have a plaintext copy of your private keys. That’s a crucial difference.
The server has an encrypted copy of your private key, which your with token decrypts with its private key. That is how a usb key can store an unlimited number of U2F credentials: The USB key isn’t storing them at all. They are stored on the server you are authenticating to.
What this also means is that if there is a backdoor in the crypto algorithm used by your token and an attacker gets a copy of the server’s U2F credentials, then you are at risk of having your private key stolen.
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.
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.
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.
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.
"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.
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. (But it would still mean many sites requesting that you replace any token found to have such a defect.)
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.
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
That’s not quite true, though. What is true is that the server does not have a plaintext copy of your private keys. That’s a crucial difference.
The server has an encrypted copy of your private key, which your with token decrypts with its private key. That is how a usb key can store an unlimited number of U2F credentials: The USB key isn’t storing them at all. They are stored on the server you are authenticating to.
What this also means is that if there is a backdoor in the crypto algorithm used by your token and an attacker gets a copy of the server’s U2F credentials, then you are at risk of having your private key stolen.