If you are reading this article, chances are you already know that passwords alone are not enough to secure your online accounts. That is why myriads of companies nowadays offer, or even enforce, the use of two-factor authentication (2FA) for accessing your account on their platforms. When it comes to optional 2FA offerings, think of sites like Gmail, Twitter and Facebook, and when it comes to mandatory 2FA implementations think more of your e-banking platform (at least in some countries, like Switzerland). Moreover, the approach of abolishing passwords altogether, called passwordless authentication, is also gaining ground and support in recent years.
FIDO (“Fast IDentity Online”), an open industry association launched back in 2013, aims to help us do exactly that: create and promote open authentication standards that make online authentication stronger and less, if at all, reliant on passwords.
How does FIDO authentication work?
FIDO Authentication is based on state-of-the-art public key cryptography in order to provide strong authentication guarantees. In FIDO, users authenticate online using client devices called FIDO authenticators (also known as security keys). Devices such as FIDO hardware tokens or even modern smartphones and computers can serve as FIDO authenticators, and can be broadly categorized as follows:
- Roaming authenticators: these are authenticators that can be attached to multiple devices using interfaces such as USB, near-field communication (NFC), and Bluetooth. Hardware security keys are an example of this category.
- Platform authenticators: these are authenticators that are embedded inside a device such as desktop/laptop computers and smartphones, and cannot be disconnected from the device.
FIDO authenticators are responsible for handling the user’s credentials (public/private key pairs) in two phases:
- Registration - A user who wishes to enable FIDO-based authentication for an online service which supports FIDO needs to first register his FIDO authenticator with that particular service. During registration, the user’s FIDO authenticator creates a new key pair, retains the private key and registers the public key with the online service.
- Authentication - When the user wishes to authenticate to the online service, his FIDO authenticator proves possession of the private key to the service by signing a challenge generated by the service. The authenticator will use its private keys to sign the challenge only after the user has “unlocked” them locally. This can be achieved in a variety of ways, depending on the capabilities of each authenticator device, ranging from simply touching the authenticator or pressing a button (which prove user presence), to more secure alternatives such as entering a PIN or using biometric authentication (which apart from asserting user presence, act as additional authentication factors). Also note that biometric information, if used, never leaves the user’s device.
The whole private/public key management is abstracted away from the user experience, removing the hassle of having to manage one’s keys: a concept extremely technical for users. Instead users are presented with simple UI elements that guide them to register their tokens, or authenticate to the online service using the pre-registered tokens.
What are all the different FIDO specifications?
Initially FIDO published two specifications: Universal Authentication Framework (UAF) and Universal 2nd Factor (U2F), collectively known as FIDO 1.0. UAF was designed to implement passwordless authentication using the available biometric authentication capabilities of modern smartphones. U2F, on the other hand, was meant to be used for two-factor authentication (passwords still being the first factor), mainly through the use of FIDO hardware security keys. U2F contained a protocol specification for communication between the client (e.g., browser) and roaming authenticators, called Client to Authenticator Protocol (CTAP), using local communication channels, such as USB, NFC, and Bluetooth.
The fact that UAF and U2F were two completely different protocols, designed for different purposes, together with lack of support from some key industry players, like Apple, contributed to a fragmented landscape and lack of widespread support for FIDO 1.0.
FIDO2 arrived later on, with the aim to provide a unified protocol for secure passwordless authentication in both mobile and desktop environments. FIDO2 provides a browser API, called Web Authentication (WebAuthn), which allows online services to use FIDO authenticators directly, without the need for traditional credentials (i.e., passwords, or even usernames). FIDO2 also contains an expanded version of CTAP, called CTAP2.
FIDO2 has the following advantages over its predecessors. First, its WebAuthn protocol has been adopted by the World Wide Web Consortium (W3C), thus making it an open web standard. Second, it is backwards-compatible with U2F and UAF which means that (a) services which use these older specifications can continue to do so, and (b) older FIDO authenticator tokens can still work with FIDO2-enabled services. More importantly, FIDO2 enjoys widespread support from modern browsers and operating systems and this is helping increase its popularity and foster wider adoption.
Oh boy, that was a lot of terminology! But what security benefits does FIDO have?
FIDO offers strong security guarantees, stemming from the use of public key cryptography. It can either serve as a strong second authentication factor in installations where passwords are still in use, or offer secure passwordless, multi-factor authentication experience, by utilizing a what-you-have factor (possession of the authenticator device) and leveraging any local authentication capabilities that the authenticators can provide (such as biometrics). Moreover, its ability to mitigate phishing attacks, makes it one of the most secure authentication solutions against remote attackers out there.
What other advantages does it bring?
A single FIDO authenticator can be used with multiple FIDO-enabled services, doing away with the need to have separate tokens for different accounts. At the same time, FIDO operates in a privacy-preserving way, as the authenticator tokens generate and use a different key pair for each online service they are registered with, hence preventing cross-service user tracking.
FIDO specifications not only tackle user authentication, but also provide the ability to perform transaction confirmation, enabling companies like banks to secure payments or other security-critical actions that a user can perform while interacting with their online applications. This also means that FIDO can be used for Strong Customer Authentication (SCA) as mandated by the EU’s PSD2 directive.
Moreover, the fact that it is an open specification and a standard, makes it safer for services to adopt and implement. Consequently, this can foster a standardized way of securely authenticating users online and providing a uniform user login experience.
It sounds like a dream! But why isn’t everyone using it already?
Even though FIDO has many advantages, it does not come without shortcomings which, someone might argue, make adoption slower. To start with, FIDO roaming authenticators, such as hardware security keys, even though not very expensive, still cost money which may be an inhibiting factor for a lot of users. Moreover, hardware tokens (be it FIDO-based or not) pose one extra thing that users have to carry around with them. Of course, FIDO tokens are typically small and can be placed in a keyfob, but how many users would carry their keyfob with them when at home? Solutions to this potential inconvenience include to have the token permanently attached to the computer, or use platform authenticators (which, as we described above, are embedded in computers and smartphones).
Another important problem stems from the fact that users can lose their FIDO tokens. A lot of online services that support FIDO authentication do not want users to be completely locked out of their account if they lose their FIDO token: services typically implement fallback authentication mechanisms, such as TOTP and SMS, to help users login, even if they lose their FIDO token. The problem is that these fallback authentication mechanisms are arguably less secure than FIDO and, if they are in use, give the attacker the ability to attack and try to defeat these mechanisms in order to gain unauthorized access, thereby completely bypassing FIDO and the higher security barrier it is supposed to offer in the first place. On the other hand, services that try to avoid this weakened security, by making FIDO strictly the only authentication mechanism for account access (such as Google’s Advanced Protection Program) incur a significant account lockout risk for their users. The users' only option there is to make sure they have more than one FIDO authenticators associated with their account, incurring in potentially extra costs and logistics to the user.
When it comes to the registration phase of FIDO, it is true that it has to be completed with an alternative channel or mechanism, such as username/password credentials, or one-time activation codes, which lack the security guarantees of public key based cryptography. This means that an attacker can mount his attack during the registration phase and for example manage to register his own FIDO authenticator with the victim’s account.
An issue which potentially plays a role in hindering adoption among e-banking and payment services, is the fact that even though FIDO specifications support transaction confirmation, FIDO authenticators need to have a display in order to securely display the transaction details for the user to approve, something that is not always possible. For example, most, if not all, FIDO hardware keys, currently do not have displays and thus lack this ability.
Finally, when deciding to roll out FIDO authentication, companies need to make sure that all their users are able to access their accounts. There are still cases when users might not be able to use FIDO (for example: they might not have a FIDO authenticator device that works with all the devices they use to login, or might not support transaction confirmation, if that is needed). At this stage, companies should consider a mixed approach: work with a partner that enables them to use FIDO as well as other strong authentication mechanisms. Users' data security is of the utmost importance for companies, but all users should be able to access their services online, one way or another.
Should you use FIDO, as a user, after all?
Given the above, hopefully the answer is clear: sure, go ahead and use it on online services that support it, but be aware and conscious of the following points.
In order to fully benefit from FIDO’s security advantages, access to your online account should rely solely on FIDO authentication and not have any fallback authentication mechanisms, such as TOTP, SMS, etc. Remember, if other authentication mechanisms are in place as fallback, attackers will try to subvert these instead of FIDO, thus neutralizing any additional security benefits that FIDO brings.
The first point naturally brings the second one. If indeed there are no fallback mechanisms in place that can grant access to your account if you lose your FIDO authenticator, then you will probably lose access forever. In order to avoid this unpleasant scenario, make sure you always have two or more FIDO authenticators in use and connected to your account(s).
Last but not least, although FIDO makes phishing attacks much harder to pull off, there are still ways through which an attacker can trick you, using sophisticated social engineering techniques, and gain unauthorized access to your account. So, do not let your guard down!
Want to learn more?
Reach out to our experts at sales@futurae.com. Here are also a few pointers to get you started in the journey of learning more about FIDO:
FIDO overview:
https://research.kudelskisecurity.com/2019/10/08/fido2-solving-the-password-problem/
FIDO and PSD2:
https://fidoalliance.org/wp-content/uploads/FIDO-PSD2_Customer_Journey_White_Paper.pdf
https://fidoalliance.org/how_fido_meets_the_rts_requirements/
More on FIDO and social engineering attacks:
https://blog.knowbe4.com/yes-googles-security-key-is-hackable