Counters in HOTP

Question

In the HOTP (HMAC-based One-time Password) algorithm the client and the server can have different counter values. Es. if an attacker tries to crack the password with no success.

How does HOPT deal with this ?

Answer 1

IETF RFC 4226 defines HOTP: An HMAC-Based One-Time Password Algorithm. The parties - authenticated (client) and authenticator (server) - establish some parameters

• A cryptographic hash function, $H$, and the default is SHA-1.
• A secret key, $K$, which is an arbitrary byte string, and must remain private
• A HOTP value length, $d$ (6–10, default is 6, and 6–8 is recommended)

Now, they use different counter but not far from each other. The reason is that the authenticator only increments after a successful authentication where the authenticated counter increased whenever a new HTOP is requested.

Let say HOTP has look-ahead synchronization window size $s$ - usually determined by the authenticator. The authenticator than try with the current counter and look forward until an $s$ amount.

Now an attacker can try $s$ amount to execute a brute-force attack. In this case, the $d$ is important the reduce the attack probability. The suggestion and common method is the lock of the system after a small number of failed attempts. This is common with the bank account authenticators. In case of locking, you contact the bank to resync are even re-keying.

One can also, put an increased delay after each failure like in Linux/Windows login failures. In the case of banking, the previous is better.

RFC 4226 for Resynchronization of the Counter

Optionally, the system MAY require the user to send a sequence of (say, 2, 3) HOTP values for resynchronization purpose, since forging a sequence of consecutive HOTP values is even more difficult than guessing a single HOTP value.

The probability of success of the adversary $Sec$ is given by

$$Sec = \frac{s v}{10^\text{d}}$$ where $v$ is the number of verification attempts.