Time-based One-time Password algorithm

The Time-based One-Time Password algorithm (TOTP) is an extension of the HMAC-based One-time Password algorithm (HOTP) generating a one-time password by instead taking uniqueness from 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.

Because of latency, both network and human, and unsynchronised clocks, the one-time password must validate over a range of times between the authenticator and the authenticated. Here, time is downsampled into larger durations (e.g., 30 seconds) to allow for validity between the parties. However, as with HOTP the decreased uniqueness requires additional countermeasures, such as rate limiting.

Contents

Algorithm

To establish TOTP authentication, the authenticated and authenticator must pre-establish both the HOTP parameters and the following TOTP parameters:

• T₀, the Unix time from which to start counting time steps (default is 0)
• T_X, an interval which will be used to calculate the value of the counter C_T (default is 30 seconds)

Both the authenticator and the authenticatee compute the TOTP value, then the authenticator checks if the TOTP value supplied by the authenticated matches the locally-generated TOTP value. Some authenticators allow values that should have been generated before or after the current time in order to account for slight clock skews, network latency and user delays.

TOTP value

TOTP uses the HOTP algorithm, substituting the counter with a non-decreasing value based on the current time.

TOTP value(K) = HOTP value(K, C_T)

The time counter, C_T, is an integer counting the number of durations, T_X, in the difference between the current Unix time, T, and some epoch (T₀; cf. Unix epoch); the latter values all being in integer seconds.

$C_{T}=\left\lfloor {\frac {T-T_{0}}{T_{X}}}\right\rfloor ,$

Note that Unix time is not strictly increasing; specifically, when leap seconds are inserted into UTC.

Practical considerations

For subsequent authentications to work, the clocks of the authenticated and the authenticator need to be roughly synchronized (the authenticator will typically accept one-time passwords generated from timestamps that differ by ±1 time interval from the authenticated's timestamp).

Weaknesses and vulnerabilities

TOTP values can be phished just as passwords can, though they require attackers to proxy the credentials in real time rather than collect them later on in time.

Implementations that don't limit login attempts are vulnerable to brute forcing of values.

An attacker who steals the shared secret can generate new, valid TOTP values at will. This can be a particular problem if the attacker breaches a large authentication database.

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

TOTP values are valid for longer than the amount of time they show on the screen (typically twice as long). This is a concession that the authenticating and authenticated sides' clocks can be skewed by a large margin.

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.

External links

• Step by step Python implementation in a Jupyter Notebook