Today I finally sat down to learn how #FIDO#U2F keys support an "unlimited" number of websites on a single token, without compromising privacy, and without running out of memory on the token.
Reusing the same public/private keypair would allow websites to track tokens. So, the token generates a new keypair on each registration. But where is it stored?
With the website! The token encrypts the private key with a token-specific secret and receives it back from the website on each login request.
@scy the most current implementation would be fido2 non-discoverable keys. And you should have come to my cccamp talk so you would have known in summer already :-)
I'll go over it in a fresh version at gpn22 I think
@cy Yeah, I was reading about this in, let's say, chronological order. Which means I learned about U2F first, then went on with FIDO2, got sidetracked and read about passkeys 🙃
So, can I assume from your reply that FIDO2 ND keys work basically the same like U2F? Any relevant differences?
@scy u2f is only usable as 2nd factor, as you said before. Fido2 forces "user verification", like at least clicking the key to show you are at the machine physically (as in MFA, "own" the key), whereas u2f works without (there are u2f keys without button).
aside of that the ctap protocol is different, so the handling of the authenticator on the client machine. Afaik there is more configuration the server admin can force on the client, like which authenticators are allowed.
@scy if you only use passkey as second factor, you should be fine with an old u2f device
(While still being phishing proof, in comparison to all the totp and notification apps).
U2F is built in a rather flexible way, so there's also the possibility for the token to have onboard storage and keep its private keys to itself, however it doesn't have "unlimited" storage anymore in that case.
Another nice feature of FIDO U2F is that credentials are bound to an origin, in order to prevent phishing.
A website can't simply say to your token "please sign the login for user ID XY". Instead, the browser will also include the origin (host name & port) to that request, allowing the token to check whether the requested keypair is indeed associated to that origin.
In case the website stores the encrypted private key, it also stores this information (decryptable by the registered token only).
Note that the website you're trying to log in to can only request specific U2F signatures from your token once it knows who you're trying to sign in as.
That's why this only works as a second factor, after username & password.
FIDO2 WebAuthn passkeys on the other hand can be used as a single factor, replacing username & password.
Here, the browser asks the token for the keypair(s) associated with that website – "infinite storage" is no longer possible.
And one more thing: The credentials that your token provides to the website during the registration process are signed by an "attestation key" created by the manufacturer, to prove its origin.
This allows the website to check what kind of token you have, and if it's a hardware token at all.
That's useful so that sites with high security requirements can for example require that you're really using a hardware token, instead of storing the passkey in your cloud-synced password manager.
Add comment