For decades, users have authenticated on systems with usernames and passwords. This method of authentication has not changed since the beginning of the Internet. As the Internet became a more hostile place and threats emerged, password rules were introduced. Those password rules helped to avoid guessing or reconstructing a user’s password. Over time the password rules were changed to improved the security of passwords, but things started to change again: attackers got more sophisticated and new mechanisms to protect accounts were needed.
Where it all began
Traditionally, users are authenticated using their username and password. This concept has not changed for decades. In the beginning of the Internet, there was some trust and little was protected by encryption, but as the Internet grew, the trust disappeared, and for good reason.
Over the years, more and more protocols were updated to support encryption natively or as an added layer. At the same time, password practices and rules started to improve. Instead of using your birthday, pet’s name or even worse options, stronger password rules with more complexity were enforced. This was necessary as more and more users were targeted by malicious actors.
One might think, as long as you are choosing long enough passwords and complying with the latest password rules, that your online accounts are secure. Unfortunately, something else changed too. With the first huge leaks of online platforms losing their entire password databases, a new problem arose. Many users were overwhelmed by the complexity of the password rules and reused passwords across many services. One single leak of credentials often exposed users’ credentials across many online platforms.
The introduction of OTP
In an attempt to improve security, the concept of a One-Time-Password (OTP for short) was introduced. The HOTP algorithm was introduced as RFC 4226. The concept behind HOTP is a simple algorithm that can be implemented in software, as well as low cost hardware, while still providing a secure second factor for authentication. As the RFC describes, two-factor authentication was nothing new at the time, but until then there had been no widespread standard.
What is HOTP?
HOTP, introduced in 2005, stands for “HMAC-Based One-Time Password” and describes a simple but effective algorithm to generate OTP values. In essence, the HOTP algorithm describes the generation of an OTP from a shared secret and a moving factor. The shared secret, also referred to as seed, is only known to the server and the HOTP client. The moving factor in HOTP is defined as a counter (sometimes also referred to as event-counter) and when hashed together with the seed will result in an OTP that changes for every authentication. The resulting OTP is a 6 to 8 digit value.
While the server side of the HOTP implementation will only increment the counter on successful authentication with the HOTP value, the client does not know about the success or failure of the authentication and increments every time the user requests a HOTP value. This can lead to situations that cause the counter to be out of sync. While re-synchronisation procedures are defined, they require some extra interaction from the user.
To counteract these issues, an extension to this algorithm was introduced in 2011 called TOTP.
What is TOTP?
TOTP was introduced in 2011 as an extension to HOTP as RFC6238 – Time-Based One-Time Password Algorithm.
TOTP uses the same concept of the shared secret called “seed” and a moving factor to calculate its OTP value. TOTP as well as HOTP generate a 6-8 digit OTP value. While HOTP specifies only SHA1 for hashing the seed and moving factor, TOTP defines additionally SHA2 functions as well. The most important change TOTP introduces is the change of the moving factor. Instead of a counter that can cause issues when out-of-sync, TOTP uses the Unix Timestamp as its moving factor.
Using the Unix timestamp (seconds since 1970) replaces the counter in the algorithm. The idea of using the Unix timestamp additionally or instead of the counter is already mentioned as an option in the HOTP RFC 4226. With the RFC6238 this optional idea got its only specification.
With the introduction of the TOTP in 2011, hardware tokens needed to maintain the correct time to work. Many TOTP hardware tokens were introduced and are still used today as a second factor for authenticating. With the broader use and availability of smartphones, TOTP was also added to many smartphone applications. As smartphones synchronize their time over the Internet, and users were carrying around their smartphones wherever they went, it was the next logical step. From a security point of view, this was convenient, but did often not meet the security standard.
To meet the security standards and still use TOTP as a second factor, TOTP hardware token devices are still used today. As they are offline devices, there is no risk of them being hacked.
Currently, TOTP based second factor authentication (2FA) is still used for many services. Because of its ease of use and implementation, it can be found in many hosted as well as self-hosted web-services today.
The FIDO alliance
In an attempt to increase security even further, the FIDO alliance was founded in 2012 to create an industry standard for newer and stronger online authentication. The first FIDO 1.0 protocol suite was introduced in 2014 focused on public-key cryptography instead of shared secrets like those used in HOTP and TOTP. The update to FIDO 2.0 (often referred to as FIDO2) was published in 2018. While the name “FIDO” or “FIDO2” is often used to refer to a certain protocol, it actually is a suite of protocols and standards. Additionally, the FIDO alliance introduced in 2017 a certification program with different levels: FIDO2 Level 1 (L1) and Level 2 (L2), followed by Level 3 (L3) a year later.
FIDO 2.0 suite
The FIDO 2.0 suite describes a number of protocols and standards. One of the most commonly known of these is WebAuthn. The WebAuthn API published by W3C was added to FIDO 2.0 and describes an interface for the web-browser to interact with the authenticator. The Authenticator in this context means for example a hardware security key or similar component containing the private key material and performing the cryptographic operations. The web application in WebAuthn is called the “relaying-party”. The Authenticator will create a separate keypair for each relaying-party ensuring no reuse of the same key for multiple services.
FIDO U2F
The FIDO specification defines the U2F protocol as a second factor additional to username and password. With U2F as a second factor, TOTP could be replaced. The benefits are as well the public-key cryptography used. The number of open-source self hosted solutions supporting U2F is growing. To show one example here, the git hosting service Gitea supports U2F as an additional authentication factor.
FIDO UAF
With the UAF, the FIDO alliance specification takes it one step further then U2F. The FIDO UAF is not intended as a second factor in addition to the password. The intention behind UAF is to replace password authentication completely. At the time of writing, Nextcloud seems to be one of very few open-source self-hosted solutions supporting password-less authentication.
FIDO2 Passkey or resident keys
With the second version of the FIDO specification (referred to as FIDO2), the concept of resident keys were introduced. So called “discoverable resident keys” or “discoverable credentials”. Those terms appear in the documentation of many manufacturers of security keys, as well as in software documentation. Recently, a new, easier to remember name started to emerge for these “discoverable resident keys” or “discoverable credentials”. The so called “Passkey“, which also received its own icon from the FIDO alliance.
FIDO and Open-Source
FIDO specifications define an open standard which hardware manufacturers and software developers can use to ensure a seamless experience. The WebAuthn protocol allows web-developers to interact with FIDO compliant security keys in a defined way. Local programs like openssh (starting with openssh 8.2) can use the CTAP protocol (directly or indirectly via libraries) to communicate with security keys.
The introduction of FIDO as an open standard allowed for a wide range of implementations already. Linux and macOS, as well as many web-browsers, support the FIDO specifications. Thanks to the available open libraries and frameworks, the implementation is not as complicated for developers any more.
Hardware Security Keys
More and more security keys are available with support for the FIDO2 specification. We reached out to many of them. A big “Thank you” to all the manufacturers that provided us with free samples to test not only the FIDO features but also the additional features many of them include.
While the FIDO specification seems to cover a lot of use cases, most of the software we use on a daily basis is not yet ready to support FIDO. Specifically, the latest and greatest features of FIDO2 are not available everywhere. This might change in the future. In the meantime, many security keys include more features than just what FIDO offers to bridge the gap.
Read more of my posts on my blog at https://blog.tinned-software.net/.
