Score:3

Why does FIDO2/WebAuthn really need to generate a separate key-pair for each site?

ch flag

I understand that FIDO2/WebAuthn generates a separate key-pair for each web-site (domain), and only allows a specific key-pair to be used for authentication on the same web-site (domain) who originally generated/registered that key-pair with the browser/authenticator. Also, I'm aware that this is done in order to prevent Man-in-the-Middle and "Phishing" attacks.

This specification defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users. A public key credential is created and stored by a WebAuthn Authenticator at the behest of a WebAuthn Relying Party, subject to user consent. Subsequently, the public key credential can only be accessed by origins belonging to that Relying Party. This scoping is enforced jointly by conforming User Agents and authenticators — https://www.w3.org/TR/webauthn-2/

But: Wouldn't it be sufficient to simply make the RPID (Relying Party ID, i.e. domain name) a part of the "challenge" value, i.e. the challenge would effectively become RPID || random_bytes, and require the browser/authenticator to verify that the RPID inside the challenge value is equal to the current web-site (domain), before signing? If a mismatch is detected, then someone obviously tried to trick us into signing a "foreign" challenge, which indicates a MITM/Phishing attack, so the authenticator would simply refuse to sign the challenge in that case. Problem solved?

The advantage of the above approach would be that we don't need tons of separate key-pairs for the same user. Keep in mind, that most FIDO2 devices (e.g. YubiKey) can only store a few...

Traditional TLS Client-Authentication can use a single key-pair (Client Certificate) for all sites too.

DannyNiu avatar
vu flag
If we don't use separate key-pairs, different websites will be able to track users based on their public key, which is bad for privacy. That's the most obvious reason I can think of, and there's definitely other considerations.
Uwe Kohl avatar
ch flag
So, using a separate key-pair per site (domain) is purely a "privacy" feature, but from a pure "security" point of view (i.e. ignore tracking) it would not be necessary?
Score:2
cn flag

I understand that FIDO2/WebAuthn generates a separate key-pair for each web-site (domain), and only allows a specific key-pair to be used for authentication on the same web-site (domain) who originally generated/registered that key-pair with the browser/authenticator. Also, I'm aware that this is done in order to prevent Man-in-the-Middle and "Phishing" attacks.

Generating an independent key pair per site—and per account at the site—isn't about defeating MITM or phishing attacks. An independent key pair per registration is critical for privacy, to prevent webauthn from becoming yet another method of tracking users across sites.

This makes it safe to use one device (plus a backup!) for as many sites and accounts as you want—work, personal, &c.—without turning webauthn into a passive instrument of mass surveillance. No need to carry around a keyring full of devices for different purposes.

The advantage of the above approach would be that we don't need tons of separate key-pairs for the same user. Keep in mind, that most FIDO2 devices (e.g. YubiKey) can only store a few...

There is no limit to the number of key pairs that can be ‘stored’ by a U2F/FIDO device for normal webauthn registrations, because the device doesn't actually store the key pairs at all!

Instead, the device need only store one master secret key, say $k$. This is typically used in one of two ways with credential ids (‘key handles’, in older U2F nomenclature):

  1. A credential id is $s \mathbin\Vert A_k(s)$, where $s$ is a uniform random byte string and $A_k$ is a symmetric authenticator (e.g., AES-GMAC).

    (This is how Solokeys work (steps (1), (2), (3), (4)) and how older Yubikeys work (older reference).)

  2. A credential id is $E_k(s \mathbin\Vert m)$, where $s$ is a uniform random byte string, $m$ is some metadata, and $E_k$ is an authenticated cipher (e.g., AES-GCM).

    (This is how newer Yubikeys and Yubico security keys work (newer reference).)

In both cases, the key pair is derived from the seed $s$ stored in the credential id, using the device's master secret key. The key pairs are not actually stored on the device; the device derives them on the fly from the credential ids stored on the server.

Of course, you could design a FIDO device badly so that it does store a key pair for each site it has registered. But U2F/FIDO was designed from the start to make such a bad design unnecessary.


You may be thinking of resident keys, also known as discoverable credentials. Resident keys do have the limitations you mention. They also require special software configuration tools, have poor software compatibility, require PINs, and generally make the user experience abysmal—which hurts security.

Fortunately, resident keys are normally not used in FIDO2/webauthn. You will usually encounter resident keys only in ill-conceived enterprise deployments, or if you go out of your way to inflict the trouble on yourself. For example, you can use resident keys with OpenSSH ssh-keygen, but ssh-keygen -t ecdsa-sk works fine to make non-resident FIDO ssh keys—no need for resident keys with ssh unless you want to make life difficult for yourself.

You won't accidentally hit any limit on the number of normal webauthn site registrations, because there is no such limit for any serious FIDO device on the market.

Uwe Kohl avatar
ch flag
So, it all comes down to privacy concerns, I see. Regarding the number of key-pairs, YubiKey site says *"FIDO2: the YubiKey 5 can hold up to 25 discoverable credentials"*. I'm not exactly sure what a "discoverable" credential means here, but it would seem that there **is** a limit in real-world products. YubiKey is pretty popular...
Taylor R Campbell avatar
cn flag
@UweKohl _Discoverable credential_ is synonymous with _resident key_. You don't have to worry about them unless you are dealing with an ill-conceived enterprise deployment, or you are trying to make life difficult for yourself. They are not relevant to the vast majority of FIDO/webauthn usage.
Uwe Kohl avatar
ch flag
Okay. But I still don't see how a **site-specific** *asymmetric* key-pair can be generated from a single "master key" easily and quickly. A *symmetric key* is no problem. But, e.g., generating an RSA key-pair usually requires generating a **huge** amount of pseudo-random numbers and testing whether they are prime; if they are not prime, we have to try again (usually **many** times). You *can* do this again every time, by starting with the same PRNG seed (derived from master-key and RIPD). But it would take a **long** time, every time you want to authenticate! Unless you actually store the key.
Taylor R Campbell avatar
cn flag
@UweKohl That's why few, if any, hardware FIDO keys use RSA signatures. The vast majority use ECDSA over NIST P-256, which supports very cheap deterministic key derivation. Some also support Ed25519.
Hannes avatar
gh flag
So if I understand this specificaton correctly you have a keypair for every website. That also means if you have multiple accounts on that website you can't do that anonymously. So websites for example offering a trial period you can't prolong because the can identify you. Or even when you sell your yubikey the websites can then still track you because of the same keypair. Am I right?
JBYoshi avatar
gq flag
@Hannes You can have multiple key pairs for a single website. They're distinguished by having different credential IDs. However, each key pair is scoped to a single website.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.