Passwords help to confirm the user's identity. When you type your username or email, it is your identity on the website. A password supports your claim that you are who you are. It is something you know, and nobody else knows, allegedly. What else can we use?
You can confirm your identity by proving that you have access to the specific mailbox. One-time codes or magic links can be sent to the email address. If you can access it, all good!
You need to open an email every time. Sometimes you can get "bad" emails from bad guys. So you need to be careful. A service provider can access your email too. The email ownership model is easy to understand, and widespread, but it is far from ideal.
What will happen if a verification code goes to a different email address? Someone else claims your identity. There are many potential flows with the email ownership method, but the biggest benefit is accessibility and very low cost.
Certificates, smart cards, biometrics. Something that only you can access or possess. These factors are unguessable, but you can still try to steal them.
Let's talk about public key / certificate-based authentication. It is based on public key cryptography. Two keys are to rule them all - one to encrypt the data and another one to decrypt it. A public part can be shared, but you still need to protect a private key somehow. The default way is to encrypt it with a passphrase. Now, nobody can use it without knowing a secret, nice! Just remember the secret. You cannot use a weak one, because there no brute-force protection is built in. People are bad at remembering long strings, so they utilize password managers.
Password managers use a special master password to encrypt the entire vault. You decrypt the vault with this password. Because you are doing it every day, muscle memory works for you, and it is hard to forget this master secret. Service providers store only encrypted data, if they are breached, attackers will still need to break the encryption, and modern encryption is a state of the art. Unless you typed the master password on a malicious resource, fall a victim to a phishing attack, or forgot the password, you can sleep very well!
It is annoying to type the master password every time to unlock the vault although it is the most secure method. A PIN code or some biometrics factor can be used to unlock the vault on a local device. It improves usability greatly, is it still secure? Yes, if you have a rate limiting in place. If a PIN has only 3 digits and 10 attempts are allowed to unblock the vault, attackers can try to guess the PIN with a 1% success chance. Everyone has their own risk acceptance, 1% is too high for me. I would prefer to have 8 digits PIN with 5 attempts - 0.000005% is much better compared to 1%, but I will have to type 8 digits every time. Think about this simple math when selecting a PIN - longer is better.
But it is 2022, we have biometrics available on many devices (laptops, IR web cameras, mobile phones). Yup, start using it! Just keep in mind, that fingerprint readers are not friends with water or grease. Fingerprints are great unless you are a high-profile person or worry that someone can force you to unlock the device. In this case, a PIN is your choice.
To have a good balance between security and usability you will still need to use a rate-limited "master unlocker" to protect a master secret that is a key to your digital life.
A FIDO2 device (authenticator) is a vault to store your private keys. FIDO2 relies on public key cryptography and doesn't allow to do anything stupid. It is a very strict process to comply with FIDO2 standards for device manufacturers. So they are doing a heavylifting for you!
You can ask a device to store the private key and associated metadata. It is called resident keys. Not all devices support resident keys, but when they do they can provide usernameless experience additionally to passwordless.
How does it work? We store the metadata within the authenticator, so we can ask the device to check for credentials for this specific server (relying party). If we have multiple entries, a prompt will be shown with all available options.
- Registration: We ask a device to create new resident credentials and provide information only about the relying party. The device will send the attestation response to a relying party, so the server can complete registration and store a public key associated with the device.
- Login: A relying party generates a challenge (a random string) that needs to be signed with a private key stored on the device. It responds with a signed challenge as a part of the assertion response.
You can find a great example here.
What to keep in mind when working with resident credentials?
- Not supported by some devices
- A limited number of entries (e.g. 25 resident keys for Yubikey)
- Possible duplicate entries (there is no way to restrict multiple registrations on the same device with the same username if you do not provide a username)
- A device needs to be unlocked during registration and login
Device unlocking is one of three supported user verification methods (Required, Preferred, or Discouraged). Available user verification methods are provided by a relying party (server), but an authenticator can have their own opinion. Based on my experience, all devices when working with resident keys require user verification.
So what will you get if you set the Discouraged option for resident keys flow? Exception! In some cases, a device will switch to the Required mode. This is built-in protection against unauthorized use of the device.
Let's go back to these 3 options for user verification.
- Required - a user must unlock the device for each action
- Preferred - a device will say what it wants (expect Required 😊)
- Discouraged - if user verification can be skipped (non-resident keys), it will be skipped
You can still ask for user presence, e.g. touch a Yubikey, but it is a different setting. From UX perspective, it is not very convenient and doesn't save time.
You can unlock (verify a user) the device with something you know (PIN) and something you are (biometrics). And it is exactly the same experience as you would get when unlocking a password manager. Choose your PIN wisely, enable biometrics, and use common sense.
I lost my device (authenticator), am I in trouble? Not really, after 5-10 unsuccessful attempts the specific user verification method will be disabled (e.g. fingerprint), or some devices will be wiped (8 tries on Yubikey). If the authenticator is tamper-resistant, it is game over for attackers. Lost FIDO2 device means, it cannot be used, but you cannot use it as well - think about redundancy in this case.
Hardware authenticators are better than software ones - search for TPM word from this day.
FIDO2 authenticators are not unified and may require extra steps before first use.
Windows: Enable Windows Hello
Select at least one method supported by Windows Hello, for example, PIN. If no methods are enabled, a browser handling FIDO2 request will ask to connect a security key (e.g. Yubikey).
You will need to set a PIN on a security key. Some security keys support biometrics (fingerprints), but they are more expensive and less common.
Windows Hello cannot use passwords.
Mac: You can use a password for FIDO2. A browser will ask you to enter your local password to unlock "the vault". If fingerprints or other verification methods are configured, you can use them too.
Mobile: To be honest, I'm unsure if you can use FIDO2 without setting a PIN, pattern, or registering biometrics. If you are reading about FIDO2, most likely your mobile device cannot be unlocked by swiping only 😉
It is good, but not great. There are many moving parts, I suggest starting from this page to get an idea.
Feel free to play with FIDO2 at fido2me.com.
I created this website, and no unicorns were harmed!
The source code is available here.