MFA Post 5: Time-based One-Time Passwords (TOTP)

 TOTP was designed to address some of the disadvantages of HOTP. Like HOTP it was standardized using an RFC (6238) and was adopted as an open standard by the Initiative for Open Authentication (OATH). You will sometimes hear TOTP referred to as OATH-TOTP, meaning it is using the standard OATH implementation (not to be confused with OAuth, which is not the same thing). 

Where HOTP derives the uniqueness of the code from the seed and the counter, TOTP derives uniqueness from the seed and the current time. This means TOTP relies on time synchronization and clocks. In a stand-alone hardware token without a network connection to receive time the clock sync is provided when the token is initialized. Hardware tokens have their own internal clocks, powered by a battery. Some hardware tokens, like those using a USB, Bluetooth or NFC form factor can receive clock sync from a computer when they need it, meaning they do not need batteries and internal clocks. NFC clock sync only works when the NFC devices can provide two-way communication, which only recently became available on iOS (in iOS 13.3). Software tokens typically rely on the underlying operating system for clock sync. 

The seed in TOTP is usually presented in the form of a QR code and with software code generators you typically use the device camera to register the code. It is a very quick and painless process. Some implementations on MacOS or Windows instead show you a window that you drag over the QR code to capture the seed. Both are very easy to use.

OATH-TOTP, and similar TOTP implementations, are available in a wide variety of applications and hardware. Any time you have a token code with a countdown counter, you are almost certainly looking at a TOTP code of some type. Google Authenticator, Microsoft Authenticator, Okta Verify, Duo Mobile, LastPass Authenticator, 1Password, Symantec VIP Access, and Yubico Authenticator, are just a few software implementations of OATH-TOTP. All implement the same open standard and you can use any of these applications and generate all the OATH-TOTP codes you wish with it, regardless of whether a site or service tells you to use a specific one. It is unfortunately common for IdPs to use the term "Google Authenticator" rather than the correct terminology, leading many people to believe it is the only app that works. 

Some of these, such as Okta and Duo, are more focused on larger organizations rather than consumers, but that does not mean they won't work for both. Symantec VIP Access, along with RSA SecurID, also offers software and hardware implementations of proprietary TOTP protocols.

Advantages

The open nature of OATH-TOTP and availability of reference implementations for both server and client, has made it relatively common. OATH-TOTP has a significant advantage over proprietary implementations in that end-users can have a single app that generates codes for any number of services. 

TOTP uses a time-window (see below) within which a code is valid. This leads to an interesting solution to a specific problem. Let’s say you want to build a server that throttles its responses such that clients can only get one response per minute. By setting the time window for TOTP to one minute, requiring a TOTP code on every request, and restricting clients from using the code more than once you can implement this restriction relatively easily. 

The time window in which a TOTP code is valid - typically one minute - also makes TOTP more phishing resistant than HOTP. They are not phish proof by any means. The attacker can simply use the code immediately. However, they are more phish proof than HOTP. 

1Password has an interesting implementation of OATH-TOTP. Rather than using a separate code-generator app 1Password stores the codes in the vault together with the username and password. This does, of course, increase the risk because if the vault is breached (hard, but perhaps not impossible) the passwords and the codes both leak. The vault is encrypted using your master password as well as a random string generated when you set up the vault, so cracking it would be very time-consuming, assuming proper cryptographic implementation. 

However, this implementation has a couple of very big advantages. First, it makes it very easy to use. When you use 1Password to auto-fill the password it copies the TOTP code to the clipboard so you can just paste it into the appropriate field. 

No more fumbling with separate apps and devices! Some people will argue, not completely incorrectly, that keeping your OTP code in the same vault as your password, and synching both to the cloud, increases the risk. However, as I’ve said before, ease of use often beats the best security simply because more people can use it. If it gets more people to use password manages and TOTP, we have improved security.

Second, and even  more importantly, the 1Password browser add-in validates the URL of the website you are on and will not offer to auto-fill the credentials or the TOTP code unless you are on the website for which it is tagged in the vault. As long as the user stops and questions why the credentials are not offered by 1Password when they go to a phishing site this greatly increases the phishing resistance of the TOTP codes, and the password itself. Of course, browser add-ins can have security issues, but here is a situation where accepting that risk can help make end-users considerably more phish proof! In my opinion, the risk posed by the browser add-in is greatly outweighed by the benefit it offers in terms of phishing protection. 

Disadvantages

Proprietary implementations of TOTP, such as RSA’s and Symantec’s, are in dire need of some user acceptance testing. RSA’s standard implementation requires you to append two commas and the code to your password, while Symantec’s appends just the code to the password. Both make password managers much harder to use, degrading end-user security hampering adoption of both password managers and TOTP. That combined with the cost of the tokens and the licensing fees for a technology that is functionally equivalent to an open, free standard means that proprietary TOTP implementations are almost exclusively found where usability was not really a concern, where use of a mobile phone (with software tokens) is not permitted, or where the decision was made long ago. 

Software implementations of TOTP are subject to interception by malware on the device running the software code generator. For instance, the Cerberus malware for Android now detects and extracts codes from Google Authenticator. Hardware implementations are subject to visual interception, as most people seem to hang them from badge lanyards.

Clocks in computers typically have a resolution between a millisecond (1/1000th of a second) and 15 milliseconds (1/64th of a second). However, the likelihood of two computers reporting the same time at that granularity, and being able to determine that they are that close in sync, is very low. They cannot transmit the time at run-time because of security concerns, which means the IdP must allow for a time window within which the same code is computed. By default, this window is 30 seconds in OATH-TOTP. Many implementations also have a larger window on the server, to accommodate time skew between clients and servers and, of course, time for the user to fumble with their phone to retrieve the code. Microsoft’s implementation of Kerberos - which also requires clock synchronization - is five minutes, although this large of a skew is rarely used in TOTP. However, if the authenticator (or client) and server clocks are out of sync by several minutes, TOTP will almost certainly fail.

While TOTP does shrink the window that a criminal has to use a captured code relative to HOTP, it is not phishing proof. The criminal simply has to use the code quickly. Depending on the service that was compromised there may be straightforward mechanisms to maintain persistence without having to phish another token code, but that’s beyond the scope of this article. 

TOTP, just like HOTP, is subject to the same brute forcing attacks, and mitigations, as HOTP. TOTP is also reliant on the secrecy of the seed, much like HOTP. To ensure these seeds cannot be leaked most implementations do not store the seeds. You cannot leak that which you do not have. However, this means that you cannot configure another generator app with the same seed later, so if you lose the phone with the software code generator you may be locked out of your account. To prevent this, some providers, like LastPass, store your seeds. This enables you to set up any number of apps that generate the same sequence of token codes. It does, of course, mean that those seeds are at risk of theft. A simpler way to achieve the same thing would be to simply set up multiple apps on multiple devices with the same QR code while you are setting up the first one. 

In some context you may hear about “step-up authentication”. This is where an RP requires an additional authentication step prior to performing a sensitive transaction. For instance, your bank could let you see your balances merely by opening an app that you have previously logged into. It may let you see individual transactions after logging in using a username, password, and TOTP code. To initiate an external transfer it could require you to present another TOTP code. This would be step-up authentication. The types of claims and the recency of those claims is based on the sensitivity of the transaction.

However, the lack of context for both HOTP and TOTP codes creates a vulnerability that can be exploited by an attacker when they are used for step-up authentication.  Let’s assume your bank uses step-up-authentication and requests an additional token code to transfer money to an external account. An attacker could craft a phishing page that pretended to be the bank and entice the user to type a username and password on that page. The bank now requests a TOTP code to log in. The attacker simply does the same. The victim types the code, the attacker relays it to the bank, and now the attacker is logged in. 

However, the attacker wants to transfer money out. To do that, they need an additional code. This is simply obtained. All the attacker has to do is tell the victim that the first code was incorrect, to wait 30 seconds for the code to change, and type the next code. This is perfectly normal. Identity providers do this all the time! While the user waits for the code to change the attacker tees up the transaction. The user then types the code, the attacker relays it to the bank, and the transaction proceeds. The key here is that the user has no way to know why they are receiving the request for the code. To the user a code used to log in looks exactly the same as a code used for authorizing a transaction. Unlike SMS codes, which could (but almost never do) include this context in the code, there is no way for HOTP and TOTP codes to have that kind of context. 

Finally, the secrecy of both HOTP and TOTP, is entirely reliant on the secrecy of the seeds used to generate the codes. In 2011 RSA, the maker of SecurID TOTP tokens, was breached by attackers who were targeting one of its customers. The attackers were hoping, and were correct, that RSA was holding on to the seeds for tokens it sold. Using stolen seed(s) the attackers were able to generate codes for RSAs customers. Most RSA SecurID tokens in the field ended up needing to be replaced as a result. With any authenticator where the seed is generated by the vendor you are completely dependent on the vendor ensuring there is no tampering with the seeds during manufacturing, and that those seeds are not stolen after manufacturing. This is a question that should be asked of every hardware token vendor.

 

Regardless of these disadvantages, OATH-TOTP is an important and valuable technology. If it is offered as a choice next to SMS or email based notifications, I strongly recommend that you use OATH-TOTP. Your account will be more secure as a result. If you combine it with a password manager, such as 1Password, that provides additional phishing resistance, and some vigilance of your own, it is a very strong, and convenient security solution that is well suited to most scenarios both in enterprises and for consumers