2FA / TOTP Window Calculator
Pick the period, digit count, algorithm, drift tolerance and the clock skew you expect. The calculator returns the effective acceptance window in seconds, the per-attempt brute-force probability written as 1-in-N, the attempts-per-second a blind attacker would need to reach a 50% chance inside one period, and a recommended drift setting based on the skew you entered. Useful for tuning your auth server, picking sensible defaults, or arguing with a vendor about whether 8-digit codes are worth the hassle.
Explain like I'm 5 (what even is this calculator?)
Your authenticator app spits out a fresh six digit code every 30 seconds. The server has to be a little bit forgiving, because your phone clock and the server clock are never perfectly in sync. So it accepts the code from now, the one from 30 seconds ago, and sometimes the next one too. That forgiving slice of time is the "window". Wider window, easier life for users, easier life for an attacker guessing codes. This page works out exactly how easy.
Work out your TOTP window
Fill in the form and press the button to see the window and the brute-force figures.
Effective acceptance window:
Per-attempt probability: ()
Attempts per second to 50% chance inside one period:
Recommended drift for the skew you entered:
Heads up: the window is wider than 90 seconds. RFC 6238 recommends keeping the validation window narrow. Tighten the drift, or run a once-per-account skew correction instead.
Prove it
The window in seconds is (1 + 2 × drift) × period. The per-attempt probability is the count of accepted codes divided by the code space, 10^digits. The attempts-per-second figure assumes a blind attacker, no rate limiting, no leak: it is ln(0.5) / ln(1 - p) / period, the geometric distribution rearranged for a 50% hit chance inside one period.
Source: RFC 6238 (TOTP), section 5.2 on validation window. Algorithm choice (SHA1, SHA256, SHA512) does not affect these figures; it only changes which authenticators can read your enrolment QR.
Save this calculator: press Ctrl + D to bookmark it in your browser.
Why the window matters more than the digits
Most teams worry about whether to enforce 6 digits or 8 digits and ignore the drift setting entirely, which is the wrong way round. A 6 digit code with a 30 second period and zero drift gives an attacker a one in a million chance per blind attempt. Bump drift to plus or minus three steps because someone in operations got tired of help desk tickets, and you have just multiplied the per-guess probability by seven. That is still small, but it compounds badly when the attacker has any kind of throughput.
The realistic threat model here is a credential-stuffing bot that has the password, gets thrown at the TOTP gate, and starts spraying. Without rate limiting, even a tiny per-guess probability becomes a 50% chance to land in the same time window the legitimate user is trying to log in. With rate limiting (and you should), the attacker's window of opportunity collapses, but the maths is the right starting point for setting the rate limit threshold.
Drift, skew, and the operational reality
Skew is the thing nobody plans for until it bites. A user's phone has been on aeroplane mode for a week, comes back online, and the OS has not yet hit an NTP server. The TOTP code is now 12 minutes off. The server rejects it. The user is locked out, the help desk gets a ticket, and someone in security raises the drift window from 1 to 5 to "fix" the problem. That fixes the symptom and quintuples the brute-force surface.
The right answer is to leave drift at plus or minus one step and run a one-off skew correction at enrolment, where the server stores the user-specific clock offset and applies it on every subsequent verification. RFC 6238 anticipates this in section 6: the server can resynchronise per-user. Most production-grade IAM products (Auth0, Okta, AWS Cognito, Keycloak) do this. Roll-your-own implementations usually do not, which is how the drift dial gets cranked.
Why the algorithm choice is mostly cosmetic for security
SHA1 has known collision attacks against the hash function, but TOTP does not rely on collision resistance. It uses HMAC-SHA1 with a per-account secret, and the security comes from the secret and the truncation, not from SHA1 being a strong hash. The IETF has not deprecated HMAC-SHA1 for this reason. SHA256 and SHA512 are available because the spec allows them, but compatibility with consumer authenticator apps is patchy, and the security gain is essentially nil. Pick SHA1 for compatibility unless you have a specific compliance reason.
Where to set drift in real systems
- AWS Cognito: drift is fixed at plus or minus one window. You cannot widen it. AWS chose the security side of the trade-off.
- Auth0: default plus or minus one. Configurable per tenant up to plus or minus three.
- Okta: default plus or minus one. Adaptive, can be widened temporarily on a per-user basis if skew is detected.
- Keycloak: "Look-Ahead Window" defaults to one. Operators routinely raise it to three or five to silence support tickets, which is a mistake.
- Google Authenticator and Microsoft Authenticator (consumer): client-side only. Drift handling is entirely on the server.
What this calculator does not do
It does not generate codes. It does not validate codes. It does not need a secret. It is a static set of formulas applied to the configuration you choose, run entirely in your browser. Nothing is sent anywhere, because there is nothing sensitive to send. If you need to actually generate a code, an authenticator app is the right tool. If you need to test a specific implementation, run a known test vector from RFC 6238 Appendix B.
Related calculators
TOTP is one factor. These cover the rest of the credential picture.
Frequently asked questions
What is the TOTP acceptance window?
The span of time during which a generated code is still accepted. With a 30 second period and drift of plus or minus one step, three codes are valid at any moment: previous, current, next. That is a 90 second window.
How does drift tolerance affect security?
Each step of drift on either side adds another accepted code. Six digit code space is one million. Drift of plus or minus one gives three accepted codes, so per-guess probability is three in a million. The absolute hit is small. RFC 6238 still recommends keeping it tight, ideally a single step.
What clock skew should I plan for?
Devices with NTP run sub-second skew. Realistic skew comes from offline phones, hardware tokens with no sync, or VMs with drifting host clocks. A safe rule is drift = ceil(expected_skew / period). The calculator does this for you.
Should I use 7 or 8 digit codes?
Six is the everyday standard. Eight is supported by RSA SecurID, YubiKey OATH-TOTP, and some authenticators. Eight digits raise the code space from one million to one hundred million, a useful upgrade where server rate limiting is unreliable.
Does SHA1 vs SHA256 vs SHA512 matter?
Not for the brute-force maths. The window and per-guess probability depend only on period, digits and drift. Algorithm choice affects which authenticators can read your enrolment QR. SHA1 is universally supported and remains safe for HMAC use.