What happens if I lose the key, I don't have it on me, or if I'm using a mobile UI? It seems like you need an identifier (email/username/etc) besides the hardware key for this to be practical.
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
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
2: https://support.mozilla.org/en-US/kb/privacy-web-authenticat...
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
That's not correct. The keys are random so of course there would be statistically no chance to get the same one.
However, if you actually try to do this it simply doesn't work, it says you already enrolled this authenticator, which is true. How does it know? During enrollment the site presents a list of identifiers it already knows for your account, and your browser shows this list to all your authenticators, they won't re-enroll if they recognise an identifier as their own.
This delivers a nice UX. If you have several authenticators you don't need to unplug ones that were already enrolled to enroll more. Likewise you don't need to unplug the ones that don't know, say, Facebook credentials, to log into Facebook, the browser will see OK, this authenticator can't help me, let's try the others.
If you own the backend (I have a test system for this) you can just not provide that list of existing identifiers and if you do that the authenticator will cheerfully generate a fresh key pair (different from the first one) and complete enrolment again for the new key pair. A real site should never do that.
my question is (in domain of U2F/FIDO1 and non resident keys), what exactly is resetted, and if RP (websites) will provide the same initial data on enrollment, will the second enrollment end in the same keys EVEN after reset? If not, what exactly is storred and resetted on yubikey (again, OLD ones with only U2F)
Randomize the secret key that makes your authenticator unique.
Doing this has a similar effect (cryptographically at least, it's not going to magically remove initials painted on with nail polish or something) to replacing the authenticator with a different one from the same batch.
The thing that makes the simplest possible FIDO authenticator work is a single secret symmetric key known to nobody and used only one that one specific authenticator, 256-bit AES would do, we'll call the key K.
The exact details will be proprietary, obviously there are opportunities to add features/ cost reduce the product, but basically:
When it is asked to enroll somewhere the authenticator generates a completely random elliptic curve key pair, then it signs a blob with the private key from that pair, encrypts the private key using K in AEAD mode and hands over the signed blob, the public key and the encrypted private key which it says is just a neutral opaque identifier, looks random, could be anything.
A relying party (remote web site) stores the public key, the opaque identifier (remember that's actually the private key encrypted) and some way to relate these to its existing user database.
When you use U2F or WebAuthn's second factor mode to sign in, the relying party hands back that opaque identifier. Your authenticator takes the opaque identifier and tries to decrypt it with K. AEAD mode means it'll be able to verify it minted this identifier with K and if so, get back that private key. So now it can sign a blob with the private key and prove you are still in possession of the authenticator which was enrolled.
> For each account on a given site, you'll have an independent RK.
Is this only for usernameless sites? Sites with usernames can just use normal keys, right?
> (But the only sites where you can use RKs are basically Microsoft or demos.)
How do sites request to use RK’s? Why would Microsoft request RK’s when they can use the associated email address as a unique username?
Also, I can’t find anything about hardware security keys on my Microsoft account page, much less usernameless authentication.
If there’s multiple usernameless accounts per site how does the user select which RK to use? This seems impossible. If it is in fact impossible, then only one RK per authenticator would be necessary and only one usernameless account per site per authenticator could be used.
The WebAuthn specification calls this a "Client-side-resident Public Key Credential Source" or "Resident Credential" for short.
> Is this only for usernameless sites?
It facilitates the "usernameless" flow yes, since the Resident Credential includes everything needed for the authenticator to claim you are some particular user and prove it. But it will still work for other flows.
> How do sites request to use RK’s?
Set the residentKey parameter to "required" during enrollment. Enrolling an authenticator that can't do Resident Credentials should fail in this case.
Sites which want a second factor only should pick "discouraged" which allows the authenticator to remember all the credentials if it wants to (e.g. an iPhone has gigabytes of secure Flash storage so why not) but discourages doing so.
> If there’s multiple usernameless accounts per site how does the user select which RK to use?
Potentially the authenticator has its own UI. But the CTAP2 protocol allows the host to build a UI by asking for all the valid credentials for some particular relying party (ie web site). It goes something like this:
* Host PC-> Security Key "Do you know credentials for ycombinator.com ? We're doing the usernameless thing, so I have no hints just asking"
* Security Key "Yes, here is proof I'm user 48B4C9CDA2 aka hpfr, also, I can prove 6 identities on ycombinator.com including that one"
* Host PC "OK, what's the next identity?"
* Security Key "Here is proof I'm user A29EE0F103 aka tialaramex"
(and so on, iterating through the identities quickly)
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.
1) My yubikey has NFC and works fine with my phone. Even that webauthn website demo works in a mobile browser via NFC.
2) For TOTP secrets, I enroll them in both my yubikey and in the Aegis android app. I mainly use these with the Yubico Authenticator software for windows or linux, but I can pull out my phone if I need to.
3) For any account that is using U2F, I have a second backup key (the blue security key) that I also enroll for that account.
I just wish the banking and financial industry would get onboard. For customer accounts, they are mostly using SMS, but some of them are still using personal info question (e.g. what was your first pets name) as a second factor which is horrible.
Some sites allow you to also register a standard MFA device as a fallback, and further still Google (as an example) allows you to use another device that’s already authenticated to get a one time use code (depending on your account security setup).
Once you enable AWS SSO for the "organization", you can then set up SAML SSO to your existing identity provider (e.g. G Suite, which allows multiple hardware 2FA tokens per user). You do this in the new master organization account.
You can create the corresponding users in AWS SSO, and grant them the appropriate permissions in the appropriate organization accounts.
Then you do the 2FA auth to your IdP (G Suite, or selfhosted, or whatever) and then AWS just trusts the auth from the IdP, and you get to sidestep the terrible morass that is AWS MFA configuration.
If you get stuck, email me.