If you'd like to dive deeper into the world of FIDO, we recommend reading our FIDO 201 article, our in-depth guide to FIDO Protocols, and our Evaluation of SCA Methods for PSD2.
What Is FIDO?
FIDO is an acronym for “Fast Identity Online.” The FIDO Alliance is a non-profit group that was founded in 2012 with the goal of eliminating passwords from the internet through the use of cryptographic protocols. More than 200 companies internationally comprise its membership, including some of the largest companies and governments in the world, and have voted within the FIDO Alliance to standardize these cryptographic protocols.
FIDO protocols incorporate many security improvements, including:
- The use of public key cryptography for user authentication to a website, through the use of digital signatures
- The use of hardware “authenticators” to generate and store¹ cryptographic keys
- The creation of unique cryptographic keys for each website
- The use of biometrics (where available) to authenticate the user, and no transmission of the biometric template to websites, to corroborate authentication to websites
- Enabling authentication to websites with multiple authenticators
These protocols deliver the following benefits:
- elimination of shared secrets (passwords, OTP, etc.) for Passwordless authentication
- an abatement in phishing attacks to reveal secrets
- preservation of user privacy across sites²
- increased flexibility and security for authentication
For a more detailed breakdown of FIDO protocols, read our In-depth guide to FIDO protocols: U2F, UAF, and WebAuthn (FIDO2)
Why Use FIDO?
There are many multi-factor authentication (MFA) technologies on the market (depending on your definition of “multi-factor”). So, why FIDO?
FIDO is the first “strong authentication”³ technology that was designed to address many problems: security, affordability, ease of use, and ubiquity. It takes into account many practices accepted as being in common use: the ubiquity of web applications; support for JavaScript in browsers; USB ports on every desktop and most laptops; the availability of Bluetooth Low Energy (BLE) and the Near Field Communications (NFC) on most mobile devices; compact—but strong—cryptographic keys using standard algorithms (Elliptic Curve Digital Signature Algorithm, or ECDSA); and, most importantly, a general acceptance that passwords and other shared secret authentication schemes are simply not secure enough for modern web applications.
FIDO technology gives companies deploying websites/applications (known as Relying Parties or “RP” in FIDO terminology) the advantage that they neither have to acquire authenticators for their user community, nor force users to acquire them. Although these authenticators are extremely affordable, it is anticipated that most people will end up using their smartphones as their primary FIDO authenticators4, thanks to the prevalence of advanced encryption-capable smartphones.
FIDO is not a mutually exclusive authentication technology. It can coexist with all other authentication technologies during the transition period as long as the web application is programmed to route the user through the appropriate authentication flow. Users can choose to buy an authenticator from one of dozens of manufacturers and register a key with their account at any time to increase the security associated with access to their account.
Platform manufacturers (such as the creators of operating systems like Microsoft Windows or Google Android, as well as the creators of browsers like Mozilla Firefox, Google Chrome, and Microsoft Edge) have publicly committed to the support of FIDO. Third-party vendors have also enabled support for FIDO protocols on the Apple platform.
These benefits and features give FIDO protocols overwhelming odds of changing authentication as we know it today.
How FIDO Works
There are two primary processes in FIDO. The first, Registration, is a one-time event, per site, where a user with a specific authenticator registers a new key with a specific website. The second, Authentication, is performed each time the user authenticates to access the site.
Registration, very simply, involves the following steps:
- The user is identified with a unique username at the website.
- The FIDO server sends a randomly generated challenge to the user. Depending on the FIDO protocol in use, the challenge is either delivered through a supported browser and web application, or through a platform-specific application programming interface to a rich client application (RCA).
- Having received the challenge from the browser or RCA, and having passed necessary validations, the authenticator generates a pair of cryptographic keys: a public and a corresponding private key.
- The public key is returned to the website, along with digitally signed metadata and other optional content, thus completing the Registration process.
Once registered, Authentication with the FIDO key involves the following steps:
- The user is identified by username at the website.
- The FIDO server sends a randomly generated challenge to the user along with any previously stored optional content.
- Having received the challenge, and having passed necessary validations, the authenticator digitally signs the challenge and other metadata.
- The signed response is returned to the website.
- Upon verifying the signature with the previously stored public key, the user is authenticated, thus completing the process.
FIDO and FIDO2 Protocols—U2F, UFA, and WebAuthn
FIDO consists of three protocols for strong authentication to web applications: Universal 2nd Factor (U2F), Universal Authentication Framework (UAF), and WebAuthn or FIDO2.
- Universal 2nd Factor (U2F) protocol is intended to be a simple protocol and used as a second-factor authentication scheme in addition to the first factor (generally, the user's password).
- Universal Authentication Framework (UAF) is defined as a password-less protocol for use with apps on mobile devices only.
- FIDO 2.0 and W3C Web Authentication (WebAuthn) has a JavaScript API specification to allow for similar benefits as U2F and UAF, but can be uniformly implemented in all W3C-compliant browser agents. This protocol is not yet fully standardized, but is in the process currently.
End User Choices
Clearly, short of avoiding web applications and sites that do not use FIDO-based strong authentication, end users can do little until these RPs implement FIDO and support it on their customer-facing registration and login pages. Fortunately, some of the most well-known websites in the world have already incorporated support for FIDO protocols, and risk-averse end users have choices to protect themselves:
- U2F Authenticators are available from dozens of manufacturers on various e-commerce sites. By purchasing one, they can be used to register keys with sites such as Facebook, Gmail, Salesforce, Github, etc.
- Newer Android-based smartphones from Samsung, Sony, etc., include embedded UAF Authenticators in the phones which can be used with mobile apps that incorporate strong authentication to protect users
- When FIDO2/WebAuthn is standardized, the latest versions of the Android operating system and the Windows operating system will enable the use of FIDO2 if they detect the appropriate cryptographic hardware capabilities in the device.
Visiting the FIDO Alliance's webpage for FIDO-Certified Products allows you find all certified products from around the world for each of the protocols. Unfortunately, there isn't a web page that identifies all the RPs who have implemented FIDO, which protocols they support, and how to detect that they are using FIDO. Hopefully, this gap will be addressed in a future FIDO protocol revision.
Relying Party Choices
What should RPs do given the current state of FIDO protocols?
The answer is reasonably simple. As long as web applications and sites continue to use “shared secret” authentication schemes, attackers have the potential, tools, and motivation to launch scalable attacks on such sites. While RPs may have other mitigating factors to protect themselves, to the extent these factors are based on secrets—such as one-time PINs, knowledge-based authentication, etc.—they share similar weaknesses as passwords and can be compromised without the user's and (more often than not) the RP’s knowledge.
The U2F and UAF FIDO protocols have been standardized with many dozens of commercial implementations from manufacturers, including some enterprise-scale open-source projects. These protocols and implementations will not disappear overnight even if FIDO2/WebAuthn is finalized and implemented this year.
An RP does not have to wait for the perfect solution, nor make an either-or decision. Web applications can support multiple authentication schemes simultaneously. RPs can continue to maintain existing authentication schemes in their web applications along with FIDO support; this allows users to choose the degree of strength of the authentication scheme when registering and authenticating to their sites. If an RP's user chooses to authenticate via U2F or UAF, the user has mitigated the risk for both his/herself and the RP.
Next Steps
The effort it takes to implement U2F, the simpler of the two standardized protocols, is minimal. Assuming the web application works with Mozilla Firefox, Google Chrome, or Opera, it can take less than a week to integrate U2F into the web application. Microsoft has chosen to support only WebAuthn, and only on its Edge browser on Windows 10.
With a few dozen Authenticators that can be procured from your preferred e-commerce site, a proof-of-concept can be deployed and tested for usability in less than a month. Even on a limited scale, this experience will provide many valuable lessons to software architects, programmers, system administrators, security officers, and support staff—not to mention the feedback from end users who are invited to test this capability. The experience enables RPs to refine their FIDO implementation strategy before the FIDO “network effect” kicks in. When it does, there will be a scramble to get web applications and sites FIDO-enabled as quickly as possible, since anyone not using FIDO at that time becomes the “easy mark” to attackers. Attempting to solve some of these challenges under pressure may force RPs to make implementation mistakes that, at a minimum, create stress or, at worst, leave them vulnerable even though they are using FIDO.
The good news is that the technology industry is rallying around a single strong authentication flag that aims to solve the problem of shared secret authentication once and for all. It is this author's opinion that all three protocols will serve an RP’s needs—there doesn't need to be a single winner. Just as there are different levels of risks, different classes of devices, and different use cases for how people and businesses use technology, there will be a business case for more than one FIDO protocol. The sooner RPs start learning about these protocols, the sooner they avail themselves of the opportunity to protect themselves, their company, and their company's customers.
¹ There are some authenticators that encrypt cryptographic keys and store them on the website at which they are registered; the encryption key remains on the authenticator. FIDO protocols define messages that allow retrieval of the encrypted keys automatically from a website so they may be decrypted in the hardware authenticator for use during authentication.
² Although this privacy is compromised when identity federation is in use between the user and the website they're using, since the federation service provider knows the websites to which a specific user is authenticating.
³ Defined as the use of public-key cryptography with a hardware-based authenticator.
4 However, it is also likely that many users will end up having an external authenticator, too, not only as a backup to the primary authenticator in the smartphone—but also when a web application precludes the use of the smartphone as an authenticator.
