Resynchronize within a bounded window

A failed search leaves the server counter unchanged; a match advances past its counter.

• The token increments whenever a new HOTP is requested, while the server counter moves only after a successful HOTP authentication. Accidental presses therefore put the token ahead. A bounded look-ahead size s is RECOMMENDED; s SHOULD be as low as usability permits (§7.4).
• Explicit example window convention from Appendix A.3: server next 1 and s=3 means candidate counters1, 2, 3, not1 through 4. The token generated and did not submit1 and 2; it now submits Appendix D counter 3 code 969429. The server computes each candidate with its own K.
• On a match at 3, the server advances to4, beyond the matched counter, not merely from 1 to 2. A no-match result leaves it unchanged (Appendix A.3). Held technical erratum 2402 clarifies token/server variable naming; the diagram names them separately without claiming the erratum is verified.
• Replay example: with server next 4 and s=3, eligible counters are4, 5, 6. Previously consumed counter 3 is outside that range, and969429 matches none of these chosen public vectors. The failure arrow stops before acceptance. A new future counter can coincidentally have the same digits; replay prevention relies on consuming state, not globally unique codes.
• The server MAY require a sequence of two or three codes for resynchronization (§7.4). That optional extension and the separately transmitted counter protocol in Appendix E.4 are not silently assumed here. Failed attempts still count toward the server’s attempt limit; a broader search increases guessing exposure (§§6–7.3).