There are 3 different protocols that are part of the FIDO standards.
The first protocol is called UAF (Universal authentication framework) which is a standard that completely replaces passwords with a device with which you are going to authenticate. UAF is a multi-factor authentication standard meaning that on a user device, users will be entering a pin code or enter biometric data (verified locally) and then the device authenticates online to the service.
The second protocol, U2F is a protocol that exists to deal with legacy password systems so instead of breaking up completely the authentication procedure that some service providers have in place, the idea is to continue using the login and password but add the possession factor for strong authentication.
FIDO2 standard integrates FIDO standard authentication in the web browsers and in platforms more generally speaking is based on two different components:
WebAuthN standard, which are APIs specified by the W3C and supported by the latest browsers including Firefox, Edge and Chrome and most Recent Safari to facilitate the introduction of strong customer authentication in web-based applications.
The second aspect of FIDO is CTAP (Client to Authenticate Protocol) which facilitates the connection between a platform like a PC to an external device like a USB key or a smart card or even a phone.
User Authentication has two authentication mechanisms; one which connects the device to an external server (Remote), and one which uses the device by itself (Local). Proprietary biometrics are local on-chip authentications as opposed to being remote where cryptographic signature data (no biometrics specific data) is transmitted to the backend server for verification and therefore providing proof of claimed identity.
There is no out of the box strong customer authentication capability with proprietary biometrics. Given the local nature of proprietary biometrics authentication, there are numerous weaknesses worth mentioning.
There are multiple ways to implement proprietary biometric solutions, each carries considerable risk. Implementations vary from using APIs local to the operation system, cached credentials, all the way to using long-lived refresh tokens. Regardless of which implementation your application employs, inherent risks include:
No phishing resistance
No ability to do transaction confirmation
Hard to manage revocation of the long-living refresh token
The founding principles of the FIDO specification are privacy, security, and credential scaling which have proven to be beneficial for maximizing authentication capabilities. Multiple industries are consolidating towards open banking, requiring a greater need for comprehensive solutions that adhere to FIDO standards.
FIDO’s open standard applies to all platforms (Web, iOS, Android, etc). This allows organizations to leverage it at scale, eliminating the need to download special applications or special extensions.
Finally, by utilizing FIDO solutions, organizations will benefit from leveraging the industry momentum around the FIDO standard and reducing their compliance efforts significantly.
The FIDO protocol is a phishing proof authentication protocol with strong attention to the user experience. It was developed by the FIDO Alliance, a consortium of 300+ companies that work to make commerce more secure, frictionless, and phishing free. More and more large enterprises have recognized the significant benefits of adopting this protocol.
Google has experienced zero successful internal phishing attacks since they moved their employees to FIDO 3
LoginID currently supports FIDO UAF and FIDO2 protocols:
UAF is mobile-centric. It has usernameless, passwordless modes as well as transaction confirmation
FIDO2 is web-oriented, developed as a joint project between W3C and the FIDO Alliance
FIDO UAF introduces additional security as:
No credentials are stored
All following authentications are done via FIDO and are protected by an asymmetric digital signature, which makes it impossible for an attacker to forge
Stolen cookies pose little threat, as any high operations are protected by transaction confirmation
No refresh token or static secrets, which reduces attack surfaces significantly
FIDO2 is a web-centric passwordless authentication protocol. It was developed in cooperation between the FIDO Alliance and W3C (World Wide Web Consortium) and is now supported by all major browsers and platforms. It is the successor of the FIDO U2F protocol. New features/functions include:
Easy JS API
Provides 2FA (Username/Password + FIDO2), Passwordless (Username + FIDO2) and Usernameless (Just press login)
Supported by all major browsers (Chrome, Firefox, Edge, Safari)
Users don’t need to buy security keys as platform authenticators are available in Windows 10, and Android 7+, with iOS and macOS coming soon
Enterprise friendly and works with Windows Hello
The principles of FIDO authentication, in a nutshell, is shown below:
The key pairs are generated within the device (or the Authenticator). The private keys stay in the device at all times and therefore are not readable and can not be exported.
The public key, on the other hand, is exportable, and can be sent to the relying party and hence the service provider. The authentication procedure is a two-step procedure:
First with a local user verification step where the user presents something to the Authenticator, for example, it will enter a pin code which will be verified locally by the Authenticator or it will present a fingerprint or face recognition prompt while all input being verified locally by the Authenticator and
(after successful first step), the Authenticator will sign (through a cryptographic mechanism in FIDO) a challenge sent by the service provider to the device and the signed response is returned to the relying party for verification with the public key.
The verification of the signed response serves two purposes:
It proves you have the right device
It also proves that you did the first part correctly so it proves that the pin code or the biometric data was properly verified by the Authenticator
So by verifying the sign response as a pre-requisite, the relying party is now enabled to authenticate strongly with multi-factor authentication of the user.