Keep token and server counters distinct

Validation compares independently calculated values; it does not ask the token for the answer.

• HOTP means HMAC-Based One-Time Password. HMAC is a keyed message authentication code: a calculation that combines a secret key with input bytes. Here the changing input is an increasing counter, not a clock. The token and validation server share a unique secret K for that token (§§4–5.2).
• The moving factor C is an eight-byte counter that MUST be synchronized. A new code request increments the token counter before calculating the next value (§7.2, verified editorial erratum 5723). The server increments only after successful authentication (§7.4).
• Explicit example convention: the token last generated counter 0; the server next expects counter 1. A press advances the token to 1 and displays287082 from Appendix D. The server computes HOTP(K,1) itself and compares the received digits. Verified technical erratum 4994 corrects §7.2 to say calculated by the server.
• On success at counter 1, the server next expects2; the token last generated remains1 until another request. The same consumed counter is no longer eligible. Six-digit outputs can collide at different counters: this is counter consumption, not a promise that the displayed number can never recur.
• Counters and codes are examples, not enrollment defaults. The public ASCII secret in Appendix D is test data and MUST NOT be used as a real secret. Protocol P MUST support two-factor authentication; possession of a code alone is not the whole login (§7.1).