# Detect desynchronization in HOTP authentication [duplicate]

In HOTP authentication, is there a way for a system to detect that the token has been desynchronized? If so how does it know that the OTP was generated from a desynchronized (but valid) token and is not just a fake/random OTP?

-

## marked as duplicate by e-sushi♦, otus, DrLecter, D.W., CodesInChaos♦Aug 21 '14 at 9:40

From RFC 4226:

7.4. Resynchronization of the Counter

Although the server's counter value is only incremented after a
successful HOTP authentication, the counter on the token is
incremented every time a new HOTP is requested by the user. Because
of this, the counter values on the server and on the token might be
out of synchronization.

We RECOMMEND setting a look-ahead parameter s on the server, which defines the size of the look-ahead window. In a nutshell, the server can recalculate the next s HOTP-server values, and check them against the received HOTP client.

Synchronization of counters in this scenario simply requires the
server to calculate the next HOTP values and determine if there is a
match. 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 upper bound set by the parameter s ensures the server does not go on checking HOTP values forever (causing a denial-of-service attack) and also restricts the space of possible solutions for an attacker trying to manufacture HOTP values. s SHOULD be set as low as possible, while still ensuring that usability is not impacted.

-