Skip to content
ENExplore Calculators

TOTP Validity Calculator

Size the RFC 6238 TOTP acceptance window from the time step and drift tolerance, and see the clock skew it forgives.

About TOTP Validity Calculator

TOTP is HOTP with the counter set to floor((current time − T0) ÷ X), so validation means recomputing the code for the current step. Because client and server clocks drift, RFC 6238 lets the server also test one step either side, which triples the acceptance window to 90 seconds at the standard 30-second step and triples the false-accept probability with it. Every extra drift window you allow to placate users with bad clocks widens both the replay window for a phished code and the odds of a blind guess, so the tolerance should be a deliberate decision rather than a default nobody read.

Formulas

TOTP Validity

acceptance window = time step × (2 × drift windows + 1); clock skew tolerated = drift windows × time step.

time step
X in RFC 6238 — the counter interval, normally 30 seconds
drift windows
Steps the server also checks on each side of the current one

False-accept probability

P(random code accepted) = steps accepted ÷ 10^digits.

Worked example

With the default values below, TOTP Validity Calculator returns Total Acceptance Window of 90. Change any input above and every figure here is recalculated in your browser.

Inputs used

Time step (X)accepts 1–300 seconds
30 seconds
Drift windows accepted each sideaccepts 0–10 steps
1 steps
Client clock skewaccepts 0–3,600 seconds
12 seconds
Code lengthaccepts 4–10 digits
6 digits

Results

Total Acceptance Window
90 seconds
Time Steps Accepted
3 steps
Clock Skew Tolerated
30 seconds
Verdict for This Client
Accepted — the skew fits inside the drift window
Chance a Random Code Is Accepted
0.000300%
Average Remaining Life of a Displayed Code
15.0 seconds

Step by step

  1. 1Values used
  2. 2TOTP Validity
  3. 3False-accept probability
  4. 4Total Acceptance Window= 90 seconds
  5. 5Time Steps Accepted= 3 steps
  6. 6Clock Skew Tolerated= 30 seconds
  7. 7Verdict for This Client= Accepted — the skew fits inside the drift window
  8. 8Chance a Random Code Is Accepted= 0.000300
  9. 9Average Remaining Life of a Displayed Code= 15.0 seconds

Assumptions and limits

  • The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
  • In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
  • Figures are rounded for display to 6 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

How is TOTP Validity calculated?

acceptance window = time step × (2 × drift windows + 1); clock skew tolerated = drift windows × time step. TOTP is HOTP with the counter set to floor((current time − T0) ÷ X), so validation means recomputing the code for the current step. Because client and server clocks drift, RFC 6238 lets the server also test one step either side, which triples the acceptance window to 90 seconds at the standard 30-second step and triples the false-accept probability with it.

Why does TOTP Validity matter?

Every extra drift window you allow to placate users with bad clocks widens both the replay window for a phished code and the odds of a blind guess, so the tolerance should be a deliberate decision rather than a default nobody read.

What values do I need to enter?

This calculator takes 4 inputs: Time step (X), Drift windows accepted each side, Client clock skew, Code length. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Why is the window 90 seconds when the code shows for 30?

The server accepts the previous, current and next step. A code the user typed just as the step rolled over still validates, which is the whole point — but it also means a code stays replayable for up to 90 seconds after it was generated.

How do I handle a client whose clock is badly wrong?

Do not widen the window for everyone. RFC 6238 suggests recording a per-client drift offset once the user has successfully authenticated, then applying that offset on later validations so the shared window stays narrow.

Related Calculators

TOTP Validity Calculator – Calculate Total Acceptance Window