Time-based One-time Password Algorithm

The 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,[1] 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 = floor((unixtime(now) − unixtime(T0)) / TS),
TOTP = HOTP(SecretKey, TC),
TOTP-Value = TOTP mod 10d, where d is the desired number of digits of the one-time password.

Implementation

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

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.[2]

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 (usually two or more times longer). This is a concession that the authenticating and authenticated sides' clocks can be skewed by a large margin.

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).

Note that all One Time Password-based authentication schemes (TOTP and HOTP included, among others) are still vulnerable to session hijacking, i.e., commandeering a user's session after they have logged in. This is always a possibility when using untrusted terminals or clients. If, on the other hand, one restricts oneself to always using trusted clients on trusted terminals, then one does not strictly need One Time Password schemes, as standard passwords will be just as secure (provided an encrypted channel such as HTTPS or ssh is being used).

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.[3] In May, 2011, TOTP officially became RFC 6238.[1]

Server implementations

Company Product / Part
Microsoft Two-step Verification[4]
Salesforce.com Account access, Step-up authentication
ServiceNow [5]
Google Google Authenticator[6]
Facebook Login Approval, Code Generator[7]
Amazon Amazon Web Services[8]
Bitbucket Account access[9]
Dropbox Account access[10]
Evernote Account access[11]
Gandi Account access[12]
GitHub Account access[13]
LastPass Account access[14]
Linode Account access[15]
Wordpress.com Account access[16]
AgileBits 1Password Account access[17]
Hover Account access[18]
LinOTP
OpenAM Java based single sign-on
multiOTP Tooling, web site integration, web service, radius plugin
privacyIDEA Authentication backend
XenForo [19]
Symantec VIP Access [20]

References

  1. 1 2 "RFC 6238 - TOTP: Time-Based One-Time Password Algorithm". Retrieved July 13, 2011.
  2. ↑ "KeyUriFormat". Retrieved 5 August 2014.
  3. ↑ Alexander, Madison. "OATH Submits TOTP: Time-Based One Time Password Specification to IETF". Open Authentication. Retrieved 22 February 2010.
  4. ↑ "Microsoft Account Gets More Secure". The Official Microsoft Blog. Retrieved 17 April 2013.
  5. ↑ "Multifactor authentication".
  6. ↑ "google-authenticator – Project Hosting on Google Code". Retrieved 22 February 2010.
  7. ↑ "Extra security feature". Retrieved 30 January 2014.
  8. ↑ "AWS Multi-Factor Authentication". Retrieved 6 March 2012.
  9. ↑ "Two-step verification is here". Retrieved 11 September 2015.
  10. ↑ "Another layer of security for your Dropbox account". Retrieved 4 May 2013.
  11. ↑ "Two-Step Verification Available to All Users". Retrieved 5 January 2015.
  12. ↑ "Gandi rolls out two-factor authentication". Retrieved 21 November 2013.
  13. ↑ "About Two-Factor Authentication". Retrieved 4 September 2013.
  14. ↑ "Introducing Support for Google Authenticator". Retrieved 4 November 2011.
  15. ↑ "Linode Manager Two-Step Authentication". Retrieved 2 May 2013.
  16. ↑ "Two Step Authentication". WordPress. Retrieved 29 January 2014.
  17. ↑ "Use 1Password as an authenticator for sites with two-factor authentication". Retrieved 17 August 2016.
  18. ↑ "Two-step Signin is Here". Retrieved 25 February 2014.
  19. ↑ "[FreddysHouse] Two-factor Authentication". FreddysHouse. Retrieved 10 February 2014.
  20. ↑ "Reversing the Symantec VIP Access Provisioning Protocol". September 29, 2014.
This article is issued from Wikipedia - version of the 11/15/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.