[nickray]

No, they cannot. This is an explicit design goal of FIDO (https://fidoalliance.org/specs/fido-security-requirements/fi...).

The actual public key used for logging in to a specific site is completely random.

Optionally, the website can ask for "attestation", which is intended to prove that the public key is from a specific vendor/model. To make this also unlinkable, devices are supposed to share attestation keys in batches of 100k units.

[t0astbread]

Ah, I see! So cross-site (across multiple relying parties) linking is prevented but if I have multiple accounts within one relying party they can be linked?

[tialaramex]

FIDO (except in resident mode which we'll ignore here) requires the site requesting you authenticate to hand over a large opaque blob called an ID that your authenticator gave it when you enrolled the authenticator. This ID will be different for every time you enrolled an authenticator, and it can recognise its own IDs (using modern cryptography). To prevent you enrolling the same one twice, sites hand over a list of the ones you already enrolled and your authenticators say "I'm already enrolled here" if they recognise the ID.

So somesite.example if it suspects Jim and Candy are the same person, or at least, using the same FIDO authenticator, could do this:

When Jim signs in, they present Candy's ID. If they're right, Jim's authenticator goes "Oh I recognise this, signed". If they're wrong, Jim gets an error. Weird. Presumably on a second try they give Jim's ID and it works so that Jim isn't too suspicious.

So this attack would allow a site that strongly suspects you're doing this to prove it, to their own satisfaction anyway. But it doesn't offer any practical way for a site with more than a handful of users to just match all the users.

In resident mode, you have to admit who you are as part of signing in - you're not separately typing in an email address or username or whatever, you just press the button on your authenticator (or touch the sensor on your phone, or whatever) and you're in. This obviously means it doesn't make sense for Jim and Candy to use one device for two users on the site, and most likely their device will prohibit them from trying to enroll the second user this way.

Edited to add: If someothersite.example plays Jim or Candy's IDs from somesite.example (may it's secretly run by the same people, or they stole a database backup) to Jim (or Candy) they don't work, the IDs are bound to the domain, so these don't match.

[StavrosK]

I implemented this mode in a Django library [0] (demo on www.pastery.net) because I love the idea of not needing a password manager any more, just simply having a key with you to log in anywhere, but it doesn't seem to have widespread browser support yet.

Maybe I made a mistake, but Firefox doesn't seem to work very reliably with it, and mobile support is spotty too.

[0] https://pypi.org/project/django-webauthin/

[tialaramex]

Yes, resident credential (aka "Client discoverable") support in (at least) desktop Firefox is broken and has been for a long time. I believe it's also absent (but at least not broken) in desktop Chrome. :/

[sigmar]

Public key and key handle would still be unique and unlinkable for each account on the same site with the same u2f token. The yubico documentation is pretty good at explaining this https://developers.yubico.com/U2F/Protocol_details/Overview....

[pstrateman]

I think he's asking about have two accounts on the same website.

I'm not so sure they cannot associate.