Please consider the envrionment before printing
Physical biometrics are awesome. If only we could use them to log into a website...
Physical biometrics, such as fingerprint or facial recognition, are super useful when logging into mobile apps. It allows the user to prove their presence without having to manage a password or go through a Multi-Factor Authentication (MFA) process. So why can’t you use biometrics in the browser?
The problem is that biometrics are not suitable for sending across the internet from the user's device to your web server.
Let's use fingerprints as an example. Your database contains fingerprint data for each of your users, and you allow users to authenticate using a fingerprint scanner. In the event of a breach, your users can’t exactly reset their biometrics. Using the fingerprint example, a user will only have 10 different credentials to use, at best. Unless they start using their pets.
Biometric data stored on a web server causes real issues with credential re-use. Your users cannot randomize their fingerprints across each website. Instead, the forum they just signed up to now has the same credentials that they use for their bank account. Not ideal.
You also cannot identify a user from biometrics alone; some other factor will always be required. Once you have millions of users, there will eventually be some false matches, where the accuracy of the biometric device will be unable to distinguish two users apart. This is much the same for passwords. Once you have enough users, you will eventually have two users who have the same password.
As a result, physical biometrics should only be used for local authentication and in combination with another factor. Biometric data should never leave the device and be sent across the internet. In fact, NIST recommends that you only ever use biometrics (something you are) in combination with another authentication factor, such as a username (something you know). Or even better, something you have.
So, how can you use local, physical biometrics in an ASP.NET Core website? And can you do so using an open, standardized protocol?
This is where FIDO2 comes into its own. If you haven’t heard of FIDO already, you may know of its child specifications WebAuthn, CTAP, and U2F. Maybe you’ve seen people with those funky blue Yubikeys hanging off their keychain. FIDO is a fast-growing internet standard that lets you use strong cryptography backed by physical authenticators such as a Yubikey or Solo Key. However, it is much more than that.
On its own, a FIDO authenticator counts as “something you have”. It is a physical key or platform such as the TPM on your computer. However, newer FIDO authenticators can now require the user to unlock the key itself using either a password (something you know) or biometrics (something you are). Which leads us to our solution.
Let’s see how easy it is to enable FIDO2 and biometric authentication in your ASP.NET Core web application.
This example will use the FIDO for ASP.NET component from Rock Solid Knowledge. This component has been certified by the FIDO Alliance and only needs around 6 lines of server-side code to get up and running.
When using biometric authentication in your ASP.NET Core app, your login or 2FA controller action would look something like this:
IdentityServer
public async Task<IActionResult> Login(string username, string password)
{
// existing username & password validation
var challenge = await fido.InitiateAuthentication(
userId, new FidoAuthenticationRequestOptions {RequireUserVerification = true});
return View(challenge.ToBase64Dto());
}
public async Task<IActionResult> CompleteFidoLogin(Base64FidoAuthenticationResponse authResponse)
{
var result = await fido.CompleteAuthentication(authResponse.ToFidoResponse());
if (result.IsSuccess)
{
// sign in with cookie
}
return View();
}The main difference is that we are setting RequireUserVerification to true. This means that our ASP.NET Core website will not accept FIDO assertions that were generated without the user authenticating to access the key (using a PIN or biometrics).
In your WebAuthn usage, you will also need to set the userVerification flag to required. This will tell the authenticator that it must use another factor to verify the users’ identity before it responds with an assertion. If the authenticator doesn’t support user verification, the request will fail.
let userVerification = "required";
navigator.credentials.get({ publicKey: {
challenge, rpId, allowCredentials, userVerification }
})
.then((result) => { /* send result to server */ });Now, when you log into the website on your mobile phone, your users will experience the following (recorded using the Google Pixel 3):
You can find working examples of our FIDO component in Rock Solid Knowledge’s samples repository. Otherwise, you can build your own by following along with our quickstart documentation. To use our FIDO component, you will need a license key. You can download a free, one-month demo key from identityserver.com.
We’ve talked about using your mobile phone as an authenticator. Currently, that is only possible with modern Android devices. However, iOS browsers support FIDO2 and WebAuthn, and iPhones are releasing the ability to use the device itself as a FIDO authenticator in iOS 14 (2020).
But mobile phones are not the only device capable of using biometrics to protect FIDO authentication. You can also take advantage of other inbuilt biometrics devices found on your Windows PC or MAC.
Or, if you want to keep your FIDO USB authenticator, you can now even buy USB authenticators with inbuilt biometrics.
Using biometrics for authentication in ASP.NET Core is now a genuine possibility thanks to FIDO2.
Get started with a free month demo of FIDO.
