6 ms·

FIDO2 supports password-less and username-less authentication, both as a single factor, i.e. no passwords. Password-less is like 2FA but without the first fact

FIDO2 supports password-less and username-less authentication, both as a single factor, i.e. no passwords. Password-less is like 2FA but without the first factor. You type in your username, next you use the security key. Username-less is done via resident keys, that can also store the username at registration. The whole experience is just authenticating with the security key. If you use FIDO without a password (not as 2FA, but as single factor), you want to enable client-side protection like a PIN or biometric. These keys are introducing the biometric option so you can just tap, without entering a PIN. Edit: oh, this works already today, you can test it on Microsoft accounts, e.g. outlook.com

hpfr 6y ago
If you have two, say, Microsoft accounts, can you use the same FIDO2-capable authenticator for both, and can Microsoft correlate the accounts by authenticator? I know keys are unique per-site, but are they per-account? edit: The spec[1] is vague on this, but it looked like a Relying Party can't correlate accounts directly via some kind of identifier for the authenticator. It looks like individual key pairs are generated on the authenticator for each account and linked to the unique userEntity.ID given by the Relying Party. However, Mozilla warns you [2] when sites ask for additional information about your authenticator. I tested this with Yubico's demo [3]. Unfortunately, it looks like the field attestationObject.attStmt.x5c identifies the authenticator. Firefox prompts you when sites ask for the extended information and removes this field if you check a box. That's nice, I guess, but it still seems not so great. If you were to forget and use a user agent that didn't prompt you to anonymize this, the Relying Party would get the attStmt in the response and theoretically could store and correlate accounts. Interested to hear more about the reasoning behind this. edit 2: It looks like this field is necessary as a second factor when using passwordless login? On Yubico's playground [4], checking "Enable passwordless login with this key" and then checking Firefox's "Anonymize anyway" box results in no request made to the key. Without enabling passwordless login, the request still works after anonymizing. To be honest, it seems like sites should allow passwordless login without the x5c field. I don't see how an attacker couldn't come up with the x5c field if they could crack the key pair. Is my reasoning right here? 1: https://www.w3.org/TR/webauthn-1 https://www.w3.org/TR/webauthn-1 2: https://support.mozilla.org/en-US/kb/privacy-web-authentication https://support.mozilla.org/en-US/kb/privacy-web-authenticat... 3: https://demo.yubico.com/webauthn-technical https://demo.yubico.com/webauthn-technical 4: https://demo.yubico.com/playground https://demo.yubico.com/playground
- tialaramex 6y ago
  Yes, all normal sites should allow you to use WebAuthn without attestation and should default to switching it off. Apple's guidelines recommend enabling it, but that's bad advice. Attestation only makes sense if you'd actually reject authenticators you don't trust, which might make sense if you're the Foo Corp. Corporate System and you only trust genuine Important Security Inc. authenticators because you issued one to every employee and so that's another safeguard against attack (it prevents employees sidestepping security like those webcams showing an OTP key output). But for a public site and especially if you actually offer other less secure alternatives (like SMS or TOTP) it makes no sense to even ask what type of authenticator I'm using. I always tell Firefox to refuse to answer. However, the attestation certificate in that x5c field isn't a unique identifier. So basically Microsoft learns that these two users have bought the same brand and maybe (if that brand sells enough volume to make it worth changing out the EPROM or whatever in batches) the same batch, but it's supposed to be at least 10 000 different authenticators sharing "your" attestation.
- ecesena 6y ago
  You have to distinguish between resident keys and non-resident keys (that I'll just call "normal keys"). Resident keys are stored on the device, so today you can only have a limited number of RKs. This said it's a temp limitation. As usage will increase, devices will allow for more RKs. For example, if I'm not wrong, yubikeys support 25 RKs, solokeys 50. (But the only sites where you can use RKs are basically Microsoft or demos.) For each account on a given site, you'll have an independent RK. (I don't believe you can have 2 RKs for the same account on the same device, but that's an implementation detail.) Normal keys, instead, are generated on the fly. They are not stored, so a single device can support unlimited sites and accounts. When you enroll a device in, say, your primary Google account, trying to enroll the same device again produces the same cryptographic key. So, in fact, for each account you can only have one key per device. But you can have unlimited accounts times unlimited sites on a single device. If you have 2 accounts on the same site on the same device, you're correct in saying that the site can't link the 2 accounts to the same device. In addition, on the device there's nothing stored, so even someone with access to the device (say, border control) can't see what sites you used the device with. Important: this is only for non-resident keys. I can't predict the future, but my expectation is that we'll see adoption of RKs for username-less login, and non-RKs for 2FA. I personally don't particularly like RKs for privacy reasons, but the specs seem to prefer them (and the UX seems much better). See also this: https://twitter.com/0x0ece/status/1160627435668480000 https://twitter.com/0x0ece/status/1160627435668480000
fastest963 6y ago
If you're using it as a resident key (username+password) then what happens if you lose that key? How can I recover my account? I don't even know my username or my password. That seems like an oversight in the spec.

hpfr 6y ago

If you have two, say, Microsoft accounts, can you use the same FIDO2-capable authenticator for both, and can Microsoft correlate the accounts by authenticator? I know keys are unique per-site, but are they per-account? edit: The spec[1] is vague on this, but it looked like a Relying Party can't correlate accounts directly via some kind of identifier for the authenticator. It looks like individual key pairs are generated on the authenticator for each account and linked to the unique userEntity.ID given by the Relying Party. However, Mozilla warns you [2] when sites ask for additional information about your authenticator. I tested this with Yubico's demo [3]. Unfortunately, it looks like the field attestationObject.attStmt.x5c identifies the authenticator. Firefox prompts you when sites ask for the extended information and removes this field if you check a box. That's nice, I guess, but it still seems not so great. If you were to forget and use a user agent that didn't prompt you to anonymize this, the Relying Party would get the attStmt in the response and theoretically could store and correlate accounts. Interested to hear more about the reasoning behind this. edit 2: It looks like this field is necessary as a second factor when using passwordless login? On Yubico's playground [4], checking "Enable passwordless login with this key" and then checking Firefox's "Anonymize anyway" box results in no request made to the key. Without enabling passwordless login, the request still works after anonymizing. To be honest, it seems like sites should allow passwordless login without the x5c field. I don't see how an attacker couldn't come up with the x5c field if they could crack the key pair. Is my reasoning right here? 1: https://www.w3.org/TR/webauthn-1 https://www.w3.org/TR/webauthn-1 2: https://support.mozilla.org/en-US/kb/privacy-web-authentication https://support.mozilla.org/en-US/kb/privacy-web-authenticat... 3: https://demo.yubico.com/webauthn-technical https://demo.yubico.com/webauthn-technical 4: https://demo.yubico.com/playground https://demo.yubico.com/playground

tialaramex 6y ago
Yes, all normal sites should allow you to use WebAuthn without attestation and should default to switching it off. Apple's guidelines recommend enabling it, but that's bad advice. Attestation only makes sense if you'd actually reject authenticators you don't trust, which might make sense if you're the Foo Corp. Corporate System and you only trust genuine Important Security Inc. authenticators because you issued one to every employee and so that's another safeguard against attack (it prevents employees sidestepping security like those webcams showing an OTP key output). But for a public site and especially if you actually offer other less secure alternatives (like SMS or TOTP) it makes no sense to even ask what type of authenticator I'm using. I always tell Firefox to refuse to answer. However, the attestation certificate in that x5c field isn't a unique identifier. So basically Microsoft learns that these two users have bought the same brand and maybe (if that brand sells enough volume to make it worth changing out the EPROM or whatever in batches) the same batch, but it's supposed to be at least 10 000 different authenticators sharing "your" attestation.
ecesena 6y ago
You have to distinguish between resident keys and non-resident keys (that I'll just call "normal keys"). Resident keys are stored on the device, so today you can only have a limited number of RKs. This said it's a temp limitation. As usage will increase, devices will allow for more RKs. For example, if I'm not wrong, yubikeys support 25 RKs, solokeys 50. (But the only sites where you can use RKs are basically Microsoft or demos.) For each account on a given site, you'll have an independent RK. (I don't believe you can have 2 RKs for the same account on the same device, but that's an implementation detail.) Normal keys, instead, are generated on the fly. They are not stored, so a single device can support unlimited sites and accounts. When you enroll a device in, say, your primary Google account, trying to enroll the same device again produces the same cryptographic key. So, in fact, for each account you can only have one key per device. But you can have unlimited accounts times unlimited sites on a single device. If you have 2 accounts on the same site on the same device, you're correct in saying that the site can't link the 2 accounts to the same device. In addition, on the device there's nothing stored, so even someone with access to the device (say, border control) can't see what sites you used the device with. Important: this is only for non-resident keys. I can't predict the future, but my expectation is that we'll see adoption of RKs for username-less login, and non-RKs for 2FA. I personally don't particularly like RKs for privacy reasons, but the specs seem to prefer them (and the UX seems much better). See also this: https://twitter.com/0x0ece/status/1160627435668480000 https://twitter.com/0x0ece/status/1160627435668480000

fastest963 6y ago

If you're using it as a resident key (username+password) then what happens if you lose that key? How can I recover my account? I don't even know my username or my password. That seems like an oversight in the spec.