I think everyone agrees that passwords are a pain (unless you are Rainman). With hacker attempts becoming more and more sophisticated, the balance between coming up with a strong password, yet easy enough to remember…

… I just cut it short here because we all know the dilemmas with passwords. That is not what this article is about.

Then came different 2-step authentication solutions to make it more secure. The problem with those is that they are not so user-friendly and the extra complexity makes it difficult for users to activate it; so most likely they won’t, unless forced to. And also, some 2-step solutions are infringing on your privacy rights more than how they are protecting you. The quest for safer authentication goes on…

The FIDO Alliance

The FIDO Alliance is a consortium of different vendors; representing OS and webbrowser developers, hardware manufacturers, and service providers that needs stronger authentication alternatives. FIDO stands for Fast ID Online by the way.

How the FIDO protocol works

I’m going to explain the FIDO protocol in a way that is actually informal. Not full with marketing bullshit that doesn’t explain anything what it does, except that it is “FAST, FRICTIONLESS and SECURE!”.

Comparison to the old username/password model

Arguably the biggest problem with passwords is that they are stored on a central database server. If that get’s hacked, your password, and possibly millions of others, will become compromised.

Privacy by design

With FIDO authentication, no user credentials ever gets sent over the Internet. Instead you authenticate by typing a PIN code or making some kind of gesture; for example touching a device, like a Yubikey.

If you register to a new service (let’s say you for example enable passwordless login for your Nextcloud account), the local authenticator will create:

• a private key that is stored on the authenticator and;
• a public key, that is shared with the server.

Note: The server in FIDO terminology is called the Relying Party.

The benefits of this approach are great:

• First of all, the authentication data never leaves to local device , so privacy is guaranteed
• The relying party has no personal information about the users, rendering a hacking attempt on the server pointless.
• A unique private key / public key keypair is generated for each service that the user registers for. Therefore there is no way for a hacker to track what other services a specific user have registered to.

Note: This is the ideal solution. However, different services have implemented FIDO authentications in different manners. For example:

• Nextcloud still allows you to use password for login, even after FIDO is activated, which defeats the whole purpose of passwordless login!
• Protonmail uses FIDO authentication as a 2-step verification process; you can first enter username and password, then touch the authenticator to login. An improvement compared to Nextcloud, but still not where the intended purpose is supposed to be.

Biometrics done the right way

Biometrics have been a sensitive subject for me. I don’t want to share my face or fingerprints with just anyone. What if the information gets stolen? I can’t just get a pair of new fingers (OK it might be possible, but no doubt a bigger hassle than changing passwords). That is why I have been skeptic about biometrics until now.

Since FIDO authentication data never leaves the local device, that means that the bio-metrics data is never sent to anyone else. The authenticator only tells the server (relying party) that the user presented proof of who he/she claims to be. Even if someone somehow stole your fingerprint, it would be useless, unless they have also stolen your authenticator.

Backed by attestation + metadata

How does the relying party know that the authenticator can be trusted? To put in in other words: How can the relying party know that the authenticator really have verified the user correctly?

FIDO Alliance keeps an online registry of all certified authenticators. The FIDO enabled service should have a cache of that registry, that it updates regularly.

The authenticator will send metadata about the device that may include:

• The manufacturer of the device
• Device model
• What kind of device (hardware or software authenticator)
• If the user touched the device
• If the user verified his/her identity in some way (PIN, password, biometric)

Interoperability

If an authenticator is FIDO certified, it should be able to interoperate with any FIDO enabled service. But some services might require a certain standard of performance. That is why there are different levels of FIDO certification.

The biggest differences are between level 1 and level 3:

• Level 1 is the category for software-based authenticators, called UAF Authenticators. UAF = Universal Authentication Framework. A level 1 authenticator can be an app in your phone.
• Level 3 is the category for all hardware-based authenticators, called U2F authenticators. U2F = Universal Second Factor. This is the gold standard for authenticators. A Level 3 authenticator can be a Yubikey.

FIDO and transactions

Wouldn’t it be nice to leverage this technology to authenticate online transactions? All major payment providers (Visa, Mastercard, American Express, Union Pay, JCB & Discover) are members of EMVCo, which is a standard body for the payment industry. The EMVCo invented the EMV 3-D Secure protocol version 1, which had some flaws. One of them was that some customers thought it looked like phishing attempts due to HTTP redirection, so the customers abandoned their shopping carts. Together with the FIDO Alliance, they have developed EMV 3-D Secure 2.0.

How EMV 3-D Secure works

The regular traffic flow for other FIDO authentication only involves 2 parties; The user and the relying party.

With payments, there are 3 parties involved, hence the name 3-D, which stands for 3 Domains:

• The Customer
• The Merchant’s website
• The Bank, or the PSP = Payment Service Provider, which is the ultimate approver of the transaction.

3DS flow briefly explained:

1. Customer clicks purchase on the merchants website. Credit card details are sent to the merchant.

2. The merchant sends a payment request to the customers bank.

3. The bank sends an “authentication challenge request” to the customer.

4. The customer authenticates him/herself locally, using most likely either a PIN or biometrics. If the authentication was successful, the private key gets unlocked so it can sign the challenge.

5. The authentication challenge result gets sent back to the bank.

6. Assuming authentication was successful, the bank authorizes the payment to the merchant.

Note: for a more technical deepdive on 3DS, I recommend this video from the FIDO alliance together with Visa.

Note: Most 3DS payment providers that I have encountered relies on their own mobile application. I would prefer to authenticate with something like a Yubikey Bio. Since the phone is always online, who knows if someone have access to the credential store of the software authenticator.

FIDO Authentication Data in EMV 3DS Messaging

If we look under the hood, there is nothing strange going on, as long as they have followed the FIDO standard. Here is an example of a FIDO authentication using a U2F authenticator:

{
 	"rpId": "https://merchant.com",
 	"authTime": "2020-08-08T07:42:17Z",
 	"FIDOAuthenticatorReferences": [
 		{
			"publicKey":
"BJDLvkKkuXRpn3bWh_hiJQb8lJNd9kTXEmQgEwoHezkNI_VPGd3vrjrWyZTfgxVDl9_TpixrVjmEAEmegmfL2WI",
 			"aaguid": "0132d110-bf4e-4208-a403-ab4f5f12efe5",
 			"uv": true,
 			"up": true,
 			"usedForThisTransaction": true
 		}
 	]
}

Source: https://media.fidoalliance.org/wp-content/uploads/2020/09/FIDO-and-EMV-3DS-Technical-Note-2020-09-01.pdf

Explanation:

• The code output is in a JSON format.
• the “rpId” indicates that the user have authenticated to “merchant.com” If it was a UAF authenticator, it would have returned an “appId” instead.
• “aaguid” is the ID of a U2F authenticator. Note that according to the FIDO privacy whitepaper, the ID needs to be unique for every webservice that the user registers for. This is to prevent someone from mapping all the services that a specific authenticator have registered to. If it was a UAF authentication, it would return an “aaid” instead.
• “uv” stands for User Verification and means that the user are in close proximity of the device (most likely touching it) when authenticating.
• “up” stands for User Preference and indicates that the user presented some proof of his/her identity (PIN, password or biometrics).
• “usedForThisTransaction” indicates if the authentication was used for this specific session.

How to know if your biometric authenticator is safe

That is a personal question I had to ask myself the other day. It can get quite frustrating to get an answer on that when dealing with customer support, who doesn’t know what I am talking about.

You basically have to look in the specific service providers documentation, or ask them if the authenticator has been FIDO certified. If it is, they must have followed the FIDO Alliance Privacy Whitepaper, which clearly states that biometric data must never leave the local device. If the service support a U2F device, then definitely it is safe to use.

Sources

• Rob Braxman about the topic: Odysee
• Presentation from FIDO Alliance and Visa: Youtube
• FIDO UAF Overview
• FIDO and EMV-3DS Technical Note
• FIDO Privacy Whitepaper

Special Mention