If I have a single hardware key/tpm/yubikey/iphone/etc - can you create multiple users on one site? And can they tell that you're the same user? Or are you now locked to just a single user for your phone/macbook/yubikey/whatnot?
Also if multiple services colluded (or integrated with say GA) - can they (or at least GA) all tell that you're using the same hardware key across services?
Unless I'm missing something this sounds like very bad news for user privacy
YubiKey has nice explanation of this [1], it doesn't even store the usernames or anything per service. It just has single symmetric key, from which it derives the stuff.
It works like this (WebAuthn non-resident keys):
1. YubiKey contains symmetric key.
2. When you register to WebAuthn service it generates random private key/public key, encrypts the private key with symmetric key, and sends this as token to server. Along with your username and newly generated public key.
3. When you login to WebAuthn service and type your username you get back the token. YubiKey then decrypts the token to get the private key, and answers to the challenge server gives in public key.
In other words, you don't need to store the public/private keys at all, all you need on the client side (YubiKey) the symmetric key. The private keys are stored on server you login.
For WebAuthn resident keys it needs to store info, more here:
What you're asking is if the token can act as a so-called supercookie.
For the first part yes, you can re-register the key multiple times for multiple accounts on the same site, and generally speaking these are not very correlatable on the basis of the token itself, as long as you have gotten a non-dodgy token (ie, one with a unique attestation cert). There may be other ways to strongly correlate the users however, and then the token may give the final (hard) proof the site was looking for. As a trivial example, linked in does a simple correlation on src IP. If you create 2 fake LI accounts and visit from the same IP, after a ramp up time LI will ask each of them if you want to connect to the other. But in this case, LI already had the info necessary to associate the 2 accounts. The token itself isn't the tip of the spear here, that makes this possible.
Cross-site collusion is prevented by restrictions on the RP ID. So as long as the browser is functioning correctly sites cannot collude to use the token as a supercookie.
> Unless I'm missing something
Well the thing you're missing is that you're simply supposing these things. But these things are prevented by, and intentional in the design of U2F/WebAuthn.
And if you don't trust the browser, or want to protect against sophisticated correlation attacks, "just" use a different token when you want to go dark. I'm not sure why you have this underlying assumption that a person can only possess one token.
One caveat: I've no idea what you're referring to with "GA".
As for privacy, services can require additional info from your key (WebAuthn shows an additional confirmation button). This info includes the manufacturer and probably some other info (not sure about that). Otherwise it should be impossible to tell if a single key is used for multiple usernames.
Attestation information requires that at least 100k security devices share the same attestation key, so device information can't really be used to track a given user. The proposed devicePubKey extension that helps RPs reason about which device is authenticating with a given Passkey scenario also requires domain-specific DPKs, meaning multiple identities using the same authenticator are indistinguishable as far as WebAuthn is concerned.
Of course, other signals like origin IP or browser fingerprinting can be used to correlate identities.
As a user registering an authenticator with a typical site, the authenticator creates a public/private key pair and returns the public portion. Using it later tells the site it is the same authenticator as last time, without options to release much more information than the batch of authenticators it was manufactured in.
So if you register _again_, perhaps as a different user, all the site would see is that they have two users with 'Early 2021' Yubikeys. Even this level of identification still requires the site to request attestations, which the user has the option to reject.
My demo sites may have pages of users from dummy accounts, if I don't periodically clean them up. The site has no way (official or heuristics-based) to know these are all from the same person or same piece of hardware. Different sites also wouldn't see that you were the same.
The authentication and registration flows also require some act of user consent (such as tapping a key) to release _any_ information at all - you can't find out ahead of time that the user has a credential registered. This also makes sense when you think about ones which communicate transiently - my phone might not know that I authenticate with NFC until I tap that security key against the reader.
What's allowed behind the scenes can muddy this up a bit, so I'll list that out too:
1. Sites can provide a list of registered credentials to try to keep you from registering the same authenticator twice under a single account. This works as a filter during the consent process, but the browser doesn't know if say these were across multiple accounts. If a small site provided the entire list it would block you from registering the same security key against multiple accounts - but the site wouldn't know it was successful in doing so.
2. In addition to the classic second-factor mode (where the site provides all the credentials it would honor for authentication) there is a _discoverable_ mode, used by passkeys, where the site simply says "what you got" to use as a first factor. These take up storage. So some keys may have limited storage and not want to support multiple passkeys for a single website at all.
3. There is a feature called Enterprise Attestation where your system policy (or policy on a pre-provisioned security key) may report its serial number to white-listed sites. I consider this more a problem with privacy impacts with managed devices in general, and many platforms don't support that feature at all. I believe pre-provisioned security keys must wipe out any such policy on factory reset, but that would likely then limit your ability to use that key to access corporate resources.
Authenticators and clients can certainly abuse your trust and break your privacy assumptions. The platforms are generally acting as clients and limiting access for other software to act as clients to prevent correlation attacks and phishing attacks. They use API access to limit what a website or native app can request.
These clients may also block-list authenticator features or whole authenticators which do not meet their published requirements.
If I have a single hardware key/tpm/yubikey/iphone/etc - can you create multiple users on one site? And can they tell that you're the same user? Or are you now locked to just a single user for your phone/macbook/yubikey/whatnot?
Also if multiple services colluded (or integrated with say GA) - can they (or at least GA) all tell that you're using the same hardware key across services?
Unless I'm missing something this sounds like very bad news for user privacy