Time-based One-time Password Algorithm

Time-based One-time Password Algorithm (TOTP) is an algorithm that computes a one-time password from a shared secret key and the current time. It has been adopted as Internet Engineering Task Force standard RFC 6238, is the cornerstone of Initiative For Open Authentication (OATH), and is used in a number of two-factor authentication systems.

TOTP is an example of a hash-based message authentication code (HMAC). It combines a secret key with the current timestamp using a cryptographic hash function to generate a one-time password. The timestamp typically increases in 30-second intervals, so passwords generated close together in time from the same secret key will be equal.

In a typical two-factor authentication application, user authentication proceeds as follows: a user enters username and password into a website or other server, generates a one-time password for the server using TOTP running locally on a smartphone or other device, and types that password into the server as well. The server then also runs TOTP to verify the entered one-time password. For this to work, the clocks of the user's device and the server need to be roughly synchronized (the server will typically accept one-time passwords generated from timestamps that differ by ±1 time interval from the client's timestamp). A single secret key, to be used for all subsequent authentication sessions, must have been shared between the server and the user's device over a secure channel ahead of time. If some more steps are carried out, the user can also authenticate the server using TOTP.

Definition

TOTP is based on HOTP with a timestamp replacing the incrementing counter.

The current timestamp is turned into an integer time-counter (TC) by defining the start of an epoch (T0) and counting in units of a time step (TS). For example:

TC = (unixtime(now) − unixtime(T0)) / TS,

TOTP = HOTP(SecretKey, TC), where the HOTP algorithm is defined below,

TOTP-Value = TOTP mod 10^d, where d is the desired number of digits of the one-time password.

Let:

• K be a secret key,
• C be a counter,
• HMAC(K, C) = SHA1(K ⊕ 5C5C...₁₆ ∥ SHA1(K ⊕ 3636...₁₆ ∥ C)) be an HMAC calculated with the SHA-1 cryptographic hash algorithm,
• Truncate be a function that selects 4 bytes from the result of the HMAC in a defined manner.

Then we define

HOTP(K, C) = Truncate(HMAC(K,C)) & 7FFFFFFF₁₆.

The mask sets the most significant bit to 0, to prevent the number from being interpreted as negative. This guards against different implementations of the modulo operation by processors.

Implementation

According to RFC 6238, the reference implementation is as follows:

• Generate a key, K, which is an arbitrary bytestring, and share it securely with the client.
• Agree upon an epoch, T0, and an interval, TI, which will be used to calculate the value of the counter C (defaults are the Unix epoch as T0 and 30 seconds as TI)
• Agree upon a cryptographic hash method (default is SHA-1)
• Agree upon a token length, N (default is 6)

Although RFC 6238 allows different parameters to be used, the Google implementation of the authenticator app does not support T0, TI values, hash methods and token lengths different from the default. It also expects the K secret key to be entered (or supplied in a QR code) in base-32 encoding according to RFC 3548.

Once the parameters are agreed upon, token generation is as follows:

1. Calculate C as the number of times TI has elapsed after T0.
2. Compute the HMAC hash H with C as the message and K as the key (the HMAC algorithm is defined in the previous section, but also most cryptographical libraries support it). K should be passed as it is, C should be passed as a raw 64-bit unsigned integer.
3. Take the least 4 significant bits of H and use it as an offset, O.
4. Take 4 bytes from H starting at O bytes MSB, discard the most significant bit and store the rest as an (unsigned) 32-bit integer, I.
5. The token is the lowest N digits of I in base 10. If the result has fewer digits than N, pad it with zeroes from the left.

Both the server and the client compute the token, then the server checks if the token supplied by the client matches the locally generated token. Some servers allow codes that should have been generated before or after the current time in order to account for slight clock skews, network latencies and user delays.

Weaknesses and vulnerabilities

The use of shared-secrets means that customer tokens can be emulated by anyone who steals those secrets (e.g.: break-ins at the server side stealing customer database info).

Because TOTP devices have batteries that go flat, clocks that can de-sync, and because software versions are on phones that users can lose or have stolen, all real-world implementations have methods to bypass the protection (e.g.: printed codes, email-resets, etc.), which can cause a considerable support burden for large user-bases, and also gives fraudsters additional vectors to exploit.

TOTP codes are valid for longer than the amount of time they show on the screen for (usually two or more times longer).

Most TOTP codes are unprotected (always show on a device screen, or can be seen inside text messages, often without needing to unlock the phone, or can be read simply by any unwanted user (e.g.: workmate, peers, kids) opening an app)

History

A TOTP draft was developed through the collaboration of several OATH members in order to create an industry-backed standard. It complements the event-based one-time standard HOTP and offers end user organizations and enterprises more choice in selecting technologies that best fit their application requirements and security guidelines. In 2008, OATH submitted a draft version of the specification to the IETF. This version incorporates all the feedback and commentary that the authors received from the technical community based on the prior versions submitted to the IETF. In May, 2011, TOTP officially became RFC 6238.

Server implementations

• Microsoft has implemented TOTP in its "two-step verification".
• Salesforce.com has implemented TOTP for account access and for step-up authentication when accessing parts of the application that requires high level security session.
• Google has implemented TOTP in its Google Authenticator which is the basis of its two-factor authentication.
• Facebook uses TOTP for its "Login approval" and "Code generator".
• Amazon Web Services also supports TOTP for AWS console logins using Amazon Virtual MFA or Google Authenticator.
• Bitbucket, Dropbox, Evernote, Gandi, GitHub, LastPass, Linode, and WordPress have enabled the technology for account access.
• Hover has enabled the technology for account access.
• LinOTP is open source and supports various TOTP and HOTP client authenticators
• TOTP is a minimal open source TOTP implementation in PHP, with support for various authenticators including Google Authenticator
• TwoFactorAuth.Net is a well documented, well tested, open source TOTP implementation in C# available as NuGet package
• TwoFactorAuth is a well documented, well tested, open source TOTP implementation in PHP available as Composer package
• OpenAM is an open source Java based Single Sign On server that supports various TOTP and HOTP client authenticators
• multiOTP is an opensource PHP implementation for HOTP, TOTP, mOTP and other tokens. It can be used as a command line tool, integrated in a web site, as a web service, as a radius plugin, etc.
• privacyIDEA is an authentication backend that supports TOTP, HOTP, OCRA, mOTP and other token types like ssh public keys.
• XenForo has an add-on to enable the technology for account access.
• CMO COMPLIANCE a Health, Safety & Environment Software Solution has implemented TOTP for account access authentication.
• Symantec's VIP Access two-factor authentication is based on TOTP, as discovered through reverse engineering of the provisioning protocol.
• Token2 TOTPRadius : a RADIUS server designed for two-factor authentication

Client implementations

• 1Password, an OS X, Windows, iOS, Android and Windows Phone credentials-management and wallet client.
• AuthShield, a closed source iOS, Android, BlackBerry, and Windows Phone client. Other form factors include Hard Token, implementing TOTP in addition to a challenge response authentication method.
• Authy, a closed source iOS and Android client.
• Google Authenticator, a closed source (open source up to version 2.21) client for Android, iOS, and BlackBerry. There is also a PAM module for the server side.
• Firekey, an open-source, web-based client with offline capability.
• Lockdown, a closed source iOS client.
• Microsoft's Authenticator, a closed source client for Windows Phone.
• Nitrokey has various USB token models capable of HOTP, TOTP, as well as the OpenPGP card protocol. Further Nitrokey's firmware and hardware are available as open source.
• Oathgen BSD licensed command line HOTP and TOTP client for Windows, Linux, BSD and Macintosh operating systems.
• OATH Toolkit, an open source library and command line implementation of client for Linux systems, and also a PAM module for the server side.
• Red Hat's FreeOTP, an open-source client for Android, iOS, and Pebble (experimental).
• QuickAuth, a client for the Pebble smartwatch.
• Salesforce#, a client for iOS and Android.
• SailOTP, a free software Sailfish OS client.
• Zetetic STRIP (Secure Tool for Recalling Important Passwords), a password database for iOS, Android, Windows, and OS X.
• Duo Mobile, a client for iOS, Android, BlackBerry, Windows Phone, and other mobile platforms, implements TOTP in addition to a proprietary push-based authentication method.
• Authenticator, an extension for Google Chrome and Chrome OS.
• GAuth, a web application.
• TOTPME, a client for J2ME-compatible phones (including Nokia Series 40 and Symbian).
• Token2, a client for Android, iOS and Windows Phone supporting TOTP with additional PIN protection.
• Yubico Authenticator, a open source client for Android that stores secrets on a YubiKey NEO.