MFA Post 4: One-Time Passwords

 One-time passwords are very similar to SMS codes, with one major exception: they are generated by or with the user and verified by the server, not sent to you in an SMS message. Most people think of these as generated by an application, and speak of them colloquially as “Google Authenticator Codes” because that’s one of the primary apps that generate them. However, there are many many more implementations and there are two primary algorithms. In this post I will describe HMAC-Based One-Time Passwords (HOTP). Next time I will describe Time-based One-Time Passwords (TOTP). 

HOTP

Hashed Message Authentication Code (HMAC) Based One-Time Passwords, or HOTP, is an open IETF standard (RFC 4226) for generating one-time passwords based on a cryptographically computed hash. Hashes are extraordinarily useful, and this standard simply uses them for generating the same value in two places.

HOTP generation is based on several parameters:

  1. A hashing algorithm - often SHA-1 but it could be anything
  2. A seed - a secret shared with each party that is used to compute the first HOTP code
  3. A length - how long should the computed value be
  4. A counter - a monotonically increasing counter that is used for synchronization. As long as both sides have the same seed and know what the counter should be, they can generate the same value.

The first three parameters are agreed upon when the generator is first initialized. The algorithm uses these parameters to generate the code each time the user requests it. Each code is different as long as the counter is different. However, if two parties have the seed and they know what the counter should be, they can both generate the same code. This is what makes them suitable for authentication. As long as the IdP and the client agree on what the counter is, and have the same seed, they can generate the same code. As the seed is secret, the IdP can presume that if the code it generates matches the one the client provided, the client is the one they say they are.


HOTP codes are typically associated more with hardware tokens such as the older Gemalto SafeNet tokens. However, most hardware tokens today that support HOTP also support TOTP. In addition, many software applications also support HOTP alongside TOTP.


Advantages

HOTP has the advantage that it can be used offline. The generator does not need to be connected to the server that will do the verification for it to be able to generate the code, nor to anything else. This makes it suitable in air gapped environments, and for use with hardware tokens. Because HOTP is an open standard, HOTP tokens tend to cost less than closed standard tokens.


Disadvantages

HOTP has a number of disadvantages. First, they easily get out of sync. For instance, physical tokens typically have a button on them. Each time you press the button, the token generates a code. Obviously, if the relying party requires an exact match of the counter, pressing the button just once breaks synchronization. 


For this reason, a synchronization window is typically used. For instance, if the last code counter on the server is 17 and the window size is 10 the server may accept codes 18-27. In this case, you have to press the button 10 times to break synchronization. However, the tokens are designed to be kept on key chains, or hung on a lanyard, and buttons routinely get pressed. The rate of tokens that are out of sync is typically very high.


For this reason, the standard recommends, but does not require, a re-synchronization protocol. In this case, a very simple one would be that the server simply resets its counter to whatever it determined the one on the token was, as long as it was within the acceptable window. This way next time you still have 10 button presses before you fail authentication. Even with a re-synchronization protocol, however, organizations have seen many tokens go out of synchronization. Depending on how the token is designed, it may be possible to resynchronize the token, or the token may be permanently useless once it is out of sync. In addition, the user will be unable to authenticate until a new token is obtained. One organization I worked with routinely issued two tokens to users, so that they had a spare in case the first one fell out of sync. 


HOTP tokens are also completely context-less. The user has no way to tie a token request to a legitimate site or a particular transaction. This means they are easily phished along with the password.


In addition, the fact that the counter is kept on both sides of the transaction means that, as long as the relying party does not know that another code has been generated, it will still accept the current code. For instance, let’s say the current counter is 17, and let’s say the user is phished. The user presses the button and generates token code 18. The server does not know that. The criminal can now take their time using the phished password and the token code. As long as the user does not authenticate to the legitimate server using token code 19, the server will still accept code 18. While criminals have to change how they phish for credentials, this creates a window of opportunity in which they may use a phished HOTP code. In other words, HOTP does not really stop phishing. It is telling that the security analysis in the RFC that defined HOTP is solely concerned with the security of the algorithm, and does not discuss phishing at all. 


Unless the implementation implements brute force protection, an attacker can guess many token codes. While guessing the right code for a given user is unlikely, if an attacker has passwords for 10,000 users and can guess 10 codes per user, the likelihood of success is still significant. To address this server can implement a limit on login attempts, which allows the attacker to create a denial of service condition instead. Tarpitting - where the server limits login attempts by slowing them down instead - is a far better solution. 


Finally, HOTP tokens are subject to interception in several ways. First, as mentioned many people attach them to their badge lanyards. If the token code is continuously displayed on the token, it’s not hard to read it. Of course, that’s not possible for an attacker operating at a distance. However, many of the tokens are software based, such as with an app on your phone and malware on the phone could read the token code. 

Comments

Popular posts from this blog

The Busy Executive's Guide to Personal Information Security, Part 2 of ?

MFA Post 7: Other Contact Mechanisms (Email, Phone,...)

Electric Car Charger Basics