In contrast to a regular password that is valid for an unlimited number of authentication sessions until it is reset, a one-time password (OTP) is a credential that is used only once. Although the value of an OTP may seem random, it is not randomly generated, but cryptographically derived. A good OTP algorithm shall render it practically infeasible to predict future OTP values based on previous observations. The OTP is usually updated at fixed internals, for example every 30 or 60 seconds, depending on security models of specific applications.
The token (client) possessed by the user and the back-end authentication server are always in sync—they refresh the OTP by performing the same calculation at the same time with the same “derivation materials.” In other words, after initialization, the token and the server will both assume the same OTP at any given moment in the future. To prove his ownership of the token to the server, the user types in the OTP value displayed on the token at the time of authentication to satisfy the requirement of second-factor authentication, supplementing other factors (for example, the username and password).
The utilization of OTP significantly increases the difficulty of phishing attacks. The attacker’s fake web site has to also collect the OTP entered by the user. Because the OTP is valid for only a small duration, the attacker cannot save the OTP and make use of it later. Instead, the phishing server has to be set up as a real-time man-in-the-middle, where it simultaneously establishes two connections, one with the victim’s client platform and the other with the real authentication server. This makes the attack more complex and expensive. Figure 10-1 shows a real-time man-in-the-middle attack scenario.
An OTP system has two aspects to consider:
Secrecy: With reasonable resources, adversaries shall not be able to calculate or guess OTP values. Theoretically, any collision-free one-way cryptography function with a secret seed as input is qualified. The HMAC2 (hash-based message authentication code) algorithm is the most popular choice.
Synchronization: The same OTP value must be known by the server and the client at any given moment, without requiring synchronizations after initialization.
The security strength of an OTP system solely depends on the seed, so the seed must be reliably protected by both the server and the client from leakage. Traditionally, more attention has been paid to designing physically strong and tamper-resistant tokens. However, the server’s security hardenings are even more critical because if it is hacked, then likely seeds for all tokens are at risk.
RSA Security, the Security Division of EMC, designs and manufactures a well-known OTP token, SecurID. In March 2011, the company issued an open letter3 stating that its corporate security systems had identified an “extremely sophisticated cyber-attack” being mounted against it. The letter did not disclose technical details, probably due to the concern of benefiting potential attackers, but it revealed that the attack had resulted in certain information specifically related to SecurID being extracted from RSA’s systems. In the aftermath, RSA offered token replacements or free security monitoring services to its more than 30,000 SecurID customers. The breach cost EMC $66.3 million, according to the company’s earnings.
The most famous OTP standards are the HMAC-based one-time password (HOTP4) and the time-based one-time password (TOTP5).
The derivation algorithm chosen by the HOTP method is HMAC-SHA-1. The HMAC key, also referred to as seed, is a shared secret agreed by the server and the client at the time of initialization. The key may be randomly generated or calculated from a master secret of the server. The key is static for the life cycle of the client and it must be kept secret by both parties against tampering.
An HOTP is calculated as follows:
HOTP(key, counter) := Truncate(HMAC-SHA-1(key, counter))
In the HMAC-SHA-1() function, counter is the data to be hashed. The Truncate() function reduces the 160-bit keyed-hash result to a smaller size so the user can conveniently enter the HOTP on a keyboard.
The two input parameters, key and counter, are the derivation materials. They are used for providing secrecy and synchronization, respectively. After a successful authentication, both the server and the client increment the counter by one, hence the counter should always be in sync. The server automatically increments the counter once it verifies the HOTP. On the client side, for a connected token (such as via a USB port), the connected computer can programmatically increment the counter.
However, many token products are not equipped with connection capability. The advantage of a connection-less token is obviously its simple hardware and low BOM (bill of materials) cost—it needs only small tamper-resistant storage for the key and counter and an HMAC-SHA-1 logic; it does not require circuits for USB or clocking. The tradeoff is that the user has to, after a successful authentication, manually notify the token and have it increment the counter and generate the next HOTP. The notification is usually realized by the user pushing a button on the device. This manual step introduces uncertainty and potential problems for synchronization. For example, the user may accidentally push the button twice, resulting in the token’s counter value being more advanced than the server’s. To take care of such issues, the HOTP protocol defines a “look-ahead window,” where the server calculates the next s HOTPs. The authentication is accepted as long as any of the s HOTP matches the HOTP received from the client. The window size s cannot be too large, otherwise security may be compromised.
But this mechanism does not completely resolve all potential synchronization issues. Imagine the user’s three-year-old child plays with the token and pushes the button countless times. The server’s look-head window will not cover this case, and the token must be returned to factory for reinitialization.
The TOTP scheme is a variant of HOTP that replaces the counter in the HOTP with a time value, time:
TOTP(key, time) := Truncate(HMAC(key, time))
The HMAC function may be HMAC-SHA-1, HMAC-SHA-256, or HMAC-SHA-512. The time is equal to the Unix time or Epoch time (number of seconds that have elapsed since midnight UTC (coordinated universal time) of January 1, 1970) divided by a predefined interval, with the default floor function. The floor(x) function represents the greatest integer that is not greater than fraction x. The recommended interval is 30 seconds:
time := floor(Unix_time/interval)
Compared to the HOTP, the TOTP scheme uses time as the counter for synchronization, which eliminates the problems of incrementing the counter for connection-less tokens. The TOTP scheme requires a token to have clocking capability by embedding an oscillator in the device. A token’s clock drift needs to be considered and accommodated accordingly by the server. The protocol also recommends the server to implement “look-ahead” and “look-behind” windows to for resynchronization when a tolerable amount of clock drifts have occurred on the token.
The TOTP scheme is the cornerstone of the reference architecture of OATH6 (Initiative for Open Authentication), an industry-wide collaboration to promote the adoption of strong authentication.