Bound delay and reject replay
05The verifier recomputes codes using its own clock and the provisioned secret. A small, explicitly configured window can cover a code generated just before a boundary and received just after it. Matching alone does not allow reuse.
A second submission still matches the mathematical calculation but fails the prior-use check. A match is not permission to accept a replay.
Source for this drawing: RFC 6238 · Read RFC section 5.2 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- Validation window
- The bounded set of time counters a verifier is willing to compare.
- Replay
- Submitting an OTP again after it has already been successfully validated.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
The verifier MUST NOT accept a second attempt of an OTP after its first successful validation. The RFC RECOMMENDS at most one time step for network delay; wider windows increase attack exposure.
- The verifier MUST NOT accept a second attempt of an OTP after its first successful validation. The RFC RECOMMENDS at most one time step for network delay; wider windows increase attack exposure.
- Illustrative policy: at receive time 60, T=2, compare counters2 and1 for the one-step backward transmission-delay window. A code generated at 59 can therefore match the preceding step.
- This is a configured example, not a requirement to accept every preceding code or every future step. Expiry and rate-limiting policy also matter; HOTP §7.3 discusses throttling online guesses.
- After successful acceptance, retain enough validation state to reject replay. Recomputing the identical matching code without checking prior use would violate the MUST NOT.
- Clock drift is a separate issue from transmission delay. Section 6 RECOMMENDS a specific bound on permitted forward/backward drift. It describes recording detected drift after success; large drift can require additional authentication and explicit resynchronization.
The shown code94287082 uses only the published SHA-1 fixture. At receive time 60 the current-step value is 37359152 with eight digits, while the preceding-step value is 94287082. The model rejects an already-used matching counter. These examples explain policy boundaries; they are not a production login service, a prescribed database schema, a universal±1 window or a promise that every decimal string has only one possible counter.
Read the RFC section ↗