Two-Factors, Two-Channels and One-Time-Passwords

During authentication you usually present one type of credentials to get access to a system. This is called a factor und usually it is something you know, your password for example. To strengthen a login to a system, you could add one or multiple other factors. This could be something you carry with you (a security key), something you are (biometric data), somewhere you are (IP addresses, specific device details which are hard to spoof) or something you do (for example special gestures). After adding a second factor, you are using two or multiple factor authentication.

To prove that you own a special cryptographic key without exposing it, you would usually present some kind of proof which would be valid for a limited amount of time. This will often be a one-time usable password (OTP), like a generated 6-digit code. The cryptographic key would be stored inside a hardware token or an application of the mobile phone you carry around. It is not just a second PIN you remember. It would also be possible to use OTPs in an authentication as your primary factor, but static passwords are a common pattern so most of the time they are used as a second factor.

Two Channel (or Out-Of-Band) authentication is an additional way to strengthen authentication security. If you remember your static password and possess a cryptographic key on the same computer you are trying to authenticate, there is clearly only one channel used. If the second factor is generated on a dedicated device, we use a second channel. SMS would also be an example for Out-Of-Band authentication, but is not advised by NIST without any counter measures for specific attacks, see Section 5 “Out-of-Band Verifiers” and “Authentication using the Public Switched Telephone Network” in the Digital Identity Guidelines - Authentication and Lifecycle Management 800-63B.

While aiming for a multi-factor, out-of-band authentication might be the most secure option, it can bring additional requirements for account/device recovery with it. Creating a backup of a secret should not be possible, so you will need to store additional recovery codes, weakening the security measures. In the end, even adding a simple second factor on the same channel, will increase authentication security over a static password.

Security Tokens and the YubiKeys

Security tokens are usually a piece of hardware which can have multiple features. Since you usually need to possess them, a common usage is as a second factor.

An example are RSA SecureID Tokens (PDF) which are often used in an enterprise environment. They provide the user with an OTP which changes every minute. During a multi-factor authentication, it can be used as a second factor because cryptographic keys ensure you must be in possession of the hardware token. Of course, you have to keep your private keys private to prevent any attacks on the mechanism. In March/2011 RSA announced publicly an attack against their systems via spear phishing, losing some of the private keys. This lead to another attack two months later on Lockheed Martin and maybe other customers.

Picture of five old RSA security tokens (2cm x 6cm) partly with a broken display, layered above each other

Another example of a hardware security token is the YubiKey from Yubico Ltd. The CTO and one of the founders (Jakob Ehrensvärd) is part of the team authoring some of the Fido Standards, which we will look into later (U2F and WebAuthn). YubiKeys come in various shapes and different feature sets and support different types of OTPs. With some support of the industry by giving discounts buying a YubiKey (for example 20% from Github or a key for 5$USD) it became one of the more widely used security tokens outside the enterprise environment.

Picture of a single yubikey nano which fights completely in a USB-A port

There is also a credit-card-thin-fancy-e-ink-display-version from Token2 and a whole bunch of other forms and sizes from different manufacturers. In the end, choosing the right one depends on the standards you need support for.

Using mobile phones as hardware platform for OTP applications has become more and more common over the last years. The following picture shows the Google Authenticator application, supporting OATH-HOTP and OATH-TOTP.

Picture of the Google Authenticator app on a mobile phone displaying the first 3 numbers of several OTPs. A timer for each OTP indicates the usage of OATH-TOTP.

Standards and Specification Bodies

If we have a look at the currently supported, relevant specifications we can find two main industry consortiums / projects leading the authorships: OATH and Fido.

Overview of the specs mentioned in the blogpost, grouped into FIDO2 with 2UF, WebAuthN, CTAP, UAF, OATH with HOTP, TOTP and Yubico OTP

While OATH is a little bit more mature, most of the current development and changes happen arround the FIDO project.

OATH - Initiative For Open Authentication

We can find the “mission statement” directly on the OATH consortium homepage:

[..]an industry-wide collaboration to develop an open reference architecture by leveraging existing open standards for the universal adoption of strong authentication.

The members consist of IBM, Axalto, Gemplus, VeriSign and a lot of other providers for software or hardware Identity Solutions on the market. Their main goal is to provide a free-of-cost framework using open standards by either providing them themsleves or supporting standardization (for example through the IETF). They answer a couple of questions about their goals in a FAQ document (PDF).

Apart from a certification of your OATH implementation there is a list of their technical specifications containing beside others:

We will be looking into the two OTP specifications.

OATH-HOTP (A HMAC-Based OTP Algorithm)

A “Message Authentication Code” is used to verify the authenticity of a message. It can validate if the message really originates from the sender and that nobody tempered with it. Usually there is the requirement to share a secret key between the sender and the recipient to implement the validation. HMAC (RFC2104) is an implementation of that idea by using a hashing algorithm.

During the registration of your token with the authenticator, the secret key is made known to both parties. A hardware token might have a fixed key or can be configured to one. To generate a One-Time-Password, we need a so-called moving factor and our secret key. The moving factor is a changing value which ensures the password is for one time use only. HOTP makes use of a counter for that purpose. Since the authenticator increments this counter only after a successful login, there might be some synchronization issues, if the client generates more tokens without logging in. To solve this problem the authenticator usually uses a “look-ahead window”. This determines how many increments on the counter the authenticator tries when attempting to get back in sync with the OTP generator.

Side note: OATH-HOTP (RFC 4226) uses HMAC-SHA1 which might make you think of the SHA-1 collisions implemented by the CWI Amsterdam and Google Research in 2017: First collision for full SHA-1 (PDF). This is not a problem in this context, since theoretical attacks on SHA-1 are known since 2005 (see Bruce Schneier: SHA1-Broken), HMAC-SHA1 is not affected by this type of collisions and the HOTP RFC (also from 2005) includes a detailed security analysis on SHA1-Attacks. There are some implementations of OATH-HOTP with other algorithms, but usually HMAC-SHA1 is used.

Using a simple counter instead of using a real clock as the moving factor reduces a lot of the implementation complexity for a hardware device manufacturer. This way you don’t need to keep anything in-sync with the authenticator, only the counter.

OATH-TOTP (A Time-based One-time Password Algorithm)

Keeping a counter can be difficult and may need an extremely large sliding window, for example if the authenticator is easily triggered by the user and gets out of sync after a while.

TOTP specified in RFC 6238 is a rather small extension of HOTP to prevent this problem. It replaces the static counter value with the current time. To account for latencies during the input or in the network, time is usually down sampled to 30 second slices. To prevent brute force attacks, it is also advisable to rate limit any validation requests.

By eliminating the counter, it adds the requirement for the authenticator to be in sync with the current time. This may be a problem on hardware, for example due to a low battery voltage and clock drift, but not if a smartphone application is used. Of course, not using dedicated tamperproof hardware may introduce other attack vectors.

Yubico OTP

Yubico OTP seems to make use of the OATH-HOTP Algorithm and adds a YubiKey-ID as a prefix to the OTP for linking it to a specific pre-registered user id. Further parts are encrypted with a shared secret. To get a deeper look you can visit the documentation of the format or their PHP reference implementation yubikey-val on Github. More information about their opensource implementation can be found on the yubikey-val developer documentation. Accidently triggering OTPs and increasing the counter seems no problem by design because they simply accept the highest value (see the validator implementation). To mitigate attacks the counter is stored in the encrypted part of the OTP. It still seems advisable to add bruteforce protection in addition to their server hardening instructions if you try to run this on your own infrastructure.

One of the selling points of Yubico OTP is that you can use their YubiCloud SaaS to validate your users OTPs. All YubiKeys come pre-registred with the cloud, which can be verified on their demo page:

[..] To use this your YubiKey must be configured to validate against our YubiCloud service. YubiKeys are shipped with this configuration by default.

This may be interesting if you can make use of the available connector libraries.

The description on their website doesn’t come along with many details and the most detailed information I could find is their YubiCloud OTP Validation Service PDF. A wide range of software supporting the algorithm can be found on their Works With page (also interesting for the other algorithms).

Fido2

Fido2 is a project founded by the Fido Alliance and the W3C. Just to get over with the name dropping, fido means: Google, Amazon, Thales, Lenovo, Microsoft, Infineon, VMWare, RSA, Yubico, and a lot of others, see the fido member list for more details.

CTAP, WebAuthN and UAF

WebAuthN is “An API for accessing Public Key Credentials” and a W3C recommendation. It is a browser api accessible via Javascript which can create keypairs and authenticate a user with a previously stored key. Code examples can be found at the WebAuthN Guide, a demo and more references to implementations can be found at the WebAuthN Demo Page. During the authentication process the client signs a nonce with a key specific for the domain it tries to authenticate to. This makes phishing impossible, since an attacker will operate from another domain name and therefore get a useless signature.

The Client To Authenticator Protocol (CTAP) is a proposed standard of the fido alliance to make roaming authenticators like a usb security key or a smartphone accessible for clients, for example a web browser. It’s the counterpart for WebAuthN. All the major browsers do support or currently implement CTAP.

The current state of the CTAP and WebAuthN adoption is summarized at the fido alliance’s posting “FIDO2: Web Authentication (WebAuthn)”. It differs depending on the underlying operation system and hardware connection. Support for WebAuthN is available in major browsers.

The Universal Authentification Framework (UAF) provides a framework for registering a device as an authenticator and use this device instead of a password.

The fido alliance provides a “Specification Overview” with the proper use-cases.

U2F (Universal 2nd Factor)

U2F is the result of a collaboration between Google, Yubico and the hardware manufacturer NXP Semiconductors. The idea was to push stronger authentication by using a dedicated hardware security key to generate a strong second factor. This makes it possible to use a weak and easy to remember password for your online accounts. The standard laid the groundwork for the others and is now referenced as CTAP 1 and governed by the fido alliance.

Which OTP Standard should I use?

This will mostly depend on the supported OTP algorithms of the relying parties you are trying to authenticate with. Most of the online services which support 2FA will give you the possibility to use OATH-TOTP with an application on your mobile phone, such as the Google Authenticator or FreeOTP sponsored by RedHat. Usually the configuration parameters are transferred via a QR code.

If you are the owner of a YubiKey you will find wide support for Yubico OTP which you might prefer to plain OATH-HOTP. Most of the services offering Yubico OTP will depend on their free cloud service. For me this wasn’t an issue for several years now. Other security keys might just support Fido U2F.

Other aspects of the fido2 protocols go beyond only OTPs and may be subject of another blogpost.