Since working with FIDO2 and running a webinar, and conference sessions providing deep-dives into the FIDO2 protocols, I have been asked several questions by customers, conference, blog and webinar attendees and decided to put together this Q&A. Rather than just answering questions via Twitter and LinkedIn, I will build and add to this Q&A as an ongoing resource. Any questions? Follow me on Twitter (important as I may need to DM you) @john_craddock and ask away. Read my FIDO2 blog here and view the webinar here
Can I use a U2F key with a website that uses FIDO2?
A FIDO2 client will register with, and authenticate to the FIDO2 website using WebAuthn. WebAuthn is backwards-compatible with FIDO U2F. The client communicates with an authenticator either using CTAP1 or CTAP2. CTAP1 for U2F keys, CTAP2 for FIDO2 keys. Consequently, U2F keys can still be used to provide second-factor authentication. For passwordless and nameless authentication, a FIDO2 security key is required.
Can we use a FIDO key as another factor for MFA?
This scenario is fully supported. There are three basic scenarios 2FA, passwordless, and passwordless & nameless. As you will see in the answer above, a U2F key can be used instead of a FIDO key for the 2FA option.
When referring to a FIDO2 key, what is the PIN used for?
The PIN is used to verify the user to the authenticator before it will respond to a registration or authentication request. As an alternative to using a PIN, a biometric (fingerprint) can be used to verify the user. The PIN is only used if the biometric verification is not available or fails. The PIN is a shared secret between the user and the authenticator; it is not a One-Time-Password (OTP).
What is the difference between a PIN and a password?
I often hear people say “Isn’t a PIN is the same as a password? It is something you have to remember to unlock the device”.
Both a PIN and password are a shared secret between a user and a device. When a PIN is used, the secret is shared between the user and an authenticator, the PIN is securely stored on the authenticator, and the authenticator remains in the user’s possession. The PIN is never sent across the network. The PIN in combination with the authenticator provides strong authentication, something you know and something you have. This combination is considered secure enough to allow the storage of credentials for multiple relying parties (RP).
A password is a shared secret between the user and a remote RP. The password must be sent over the network when the user registers with the RP, and it is sent over the network each time the user authenticates. There are no guarantees as to how securely the RP stores the password in its credentials database. The user needs to remember multiple passwords for access to different resources. This combination results in users using predictable passwords, the same passwords on multiple sites, being vulnerable to phishing, man-in-the-middle attacks and RP database thefts.
How secure is your account if you lose or have your FIDO2 security key stolen?
When you register and authenticate with a security key, the RP can specify whether user verification (to the authenticator) is required, preferred or discouraged. In some situations, the key could be used without the need for user verification, the user just has to verify presence by touching the authenticator. For most scenarios apart from 2FA, verification should be required. When the key is used for 2FA, the finder of the key would need to know the site, and the username and password before the key could be used.
For passwordless/nameless scenarios verification should be required, and if you are using a FIDO2 security key to sign-in to Azure AD, this is always the case. Consequently, if someone found your key, assuming they didn’t have your finger as well to do biometric verification, they would need to guess your PIN. The CTAP standard specifies a maximum of eight incorrect attempts before the authenticator is blocked. Once the authenticator is blocked, it will need to be reset, and all the held credentials are lost. The minimum pin length defined in the standard is four digits. You will need to encourage users not to use 1234 or their date of birth!
The authenticator informs the client of the number of PIN attempts remaining before being blocked. The interaction with the user will be client-specific. As an example, with Windows 10 after four bad attempts, you will need to remove and reinsert the key before trying again. After a further three bad attempts, once again, you will need to remove and reinsert the key. Finally, before being blocked, you will be prompted to enter A1B2C3 and then you have one last attempt to get the PIN correct. If you fail to enter the correct PIN, the authenticator is locked and can only be recovered by resetting the device which clears all the credentials.
Of course, the veracity of the authenticator is important and the FIDO Alliance provides certification from level 1 (least secure) to level3+ read about the certification program here.
In a demo I watched, when the user was signing into Azure AD, all they had to do was touch the key. How can that be secure? Can we enforce a PIN to be used every time?
In some situations, an indication that the user is present is required, and this is done by touching the key. However, when signing in to Azure AD, user verification is always required and when you are being asked to touch the key, you are actually being requested to have your fingerprint verified. If the biometric validation fails, you will be prompted for a PIN. Watch the Video I recorded that shows an eWBM Goldengate G310 key and its indicator lights in action.
Can a user sign-in to multiple Windows 10 desktops with the same FIDO2 key?
If you wanted a user to use a biometric or PIN to sign-in to a single desktop, then Windows Hello for Business would be the best route. However, if you want a user to be able to sign-in to multiple Windows 10 desktops, then a single FIDO2 key will meet your requirements. The computer will need to be Azure AD joined or hybrid Azure AD joined and the user will be authenticated by Azure AD. The first time the user signs in an Internet connection is required. After that, it is possible to sign-in with cached credentials and this is designed to support off-line working. When signing-in to Azure AD a Primary Refresh Token is issued/renewed and this gives SSO to all Azure AD protected resources. To get a Kerberos TGT to access on-premises (via Windows Auth) resources will require the use of the new Azure AD Connect capability to create an RODC object in the on-premises AD.
If I reset a key, what happens when going to website (RP) login where previously the device and PIN had been registered?
Neither the PIN or device are registered with the website. When you go through the registration ceremony, the PIN (or biometric) verifies the user to the FIDO2 security key (authenticator). Once the user is verified the authenticator generates a public/private key pair for access to that RP. The private key remains securely in the authenticator, and the public key is passed to the site.
During sign-in, the private key is used to sign a challenge from the RP. The RP verifies the response using the user’s public key. If you reset the key, all your private keys are lost. Consequently, you will no longer have access to the RP with the reset key.
One important point is that you cannot back-up the credentials from an authenticator. Consequently, you will need to register the key, that has been reset, with the RP. How that is done depends on the RP. As an example, Azure AD allows you to register multiple keys for use with a user’s Azure AD account. If a key is reset, the user can sign-in with their second key and register the reset key or they could sign-in with their username and password + 2FA and register the key. In the future, I expect it will be possible to turn off the use of passwords, in which case you will need to have at least two keys registered.
Just to be clear when you register a second key, the keys will have different asymmetric keypairs for accessing a single Azure AD account.
If an RP doesn’t offer the capability of registering two keys for the account, then maybe you can revert to a username and password to register the reset key. Or the site might offer some form of reset workflow such as emailing you a code and or sending a code to your home address.
Comments