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

Post a Comment

Popular posts from this blog

U2F, FIDO2, and Hardware Security Keys

-
  In our journey through possession proofs we have encountered hardware factors of various kinds. HOTP and TOTP is often implemented as hardware devices, and of course, so are Smart Cards. In this post we will look at authenticators that implement the FIDO standards -  U2F, WebAuthn, and CTAP2. WebAuthn and CTAP2 are collectively part of the FIDO Alliance ’s FIDO2 protocol suite. U2F and UAF are older FIDO protocols that are supported under FIDO2. They can all be thought of as being part of the FIDO2 suite of protocols.  To understand these protocols, and their advantages and disadvantages, we need to be familiar with the three fundamental actors: Relying party (RP) - Also known as the server. This is the service that a user wishes to log into. Client - This is the application that brokers the authentication from the relying party to the authenticator and eventually the user. Much of the time, this is a web browser, but it could be any application. Authenticator - This ...
Read more

Single Sign-On

-
There are two kinds of organizations. Those that manage their single sign-on (SSO) system, and those that let their users manage their SSO. The other day I was in a discussion with a number of security leaders about how important identity management is to your security strategy. Obviously, everyone agreed that identity is very important. After all, if you don’t have a strong identity strategy pretty much no other component of your strategy will be strong. There is a reason that the first function of the NIST CSF is Identity.  However, the discussion then turned to SSO and whether it didn’t constitute putting all your eggs in one basket, and whether doing so is a good idea. Yes. SSO does constitute putting all your eggs in one basket. But, that is a good  thing. Why? Because you, as a security leader control  that basket. You know where it is. You know how it is configured. You have already required strong multi-factor authentication (MFA) on it. (You have right? If not, s...
Read more

Warning: Regulations May Harm Your Security

-
Like many of you, I have spent decades trying to devise security controls that comply with various regulatory requirements. In some cases, they are actual regulations, like FINRA 17a-4, GDPR, HIPAA, NYDFS Part 500, and PCI DSS. In other cases, the regulation is an industry standard to demonstrate adequate controls to business partners and customers, such as NIST CSF and SOC 2 Type II; or a requirement for some customers, such as FedRAMP. While every one of these is well intended and they all have some requirements that are sensible, they also have the potential to cause harm, primarily in one of two ways.  Regulatory Compliant Does Not Mean Secure Regulatory compliance is often presented as a voucher or certification. Management often celebrates that we “passed our certification”. First, most of the regulations are not actually certifications. For instance, as a merchant, you are not “certified” under the Payment Card Industry (PCI) Data Security Standard (DSS). You are assessed,...
Read more