One-Time Passwords, Explained: How TOTP Codes Protect Your Accounts
A password alone is a single secret, and single secrets leak: they are phished, reused across sites, and exposed in breaches. A one-time password adds a second factor that changes constantly, so even a code an attacker observes is useless minutes later. The most common form is TOTP, the time-based one-time password, which your authenticator app generates from a secret key and the current time. The One-Time Password Generator demonstrates TOTP generation in your browser, and understanding how it works makes the whole two-factor habit easier to trust and harder to get wrong.
TOTP is built on two ingredients: a secret key shared between the service and your authenticator app, and the current time. When you set up two-factor authentication, the service shows you a QR code or a secret string, and your app stores that secret. From then on, the app combines the secret with a counter derived from the current time, runs that combination through a cryptographic hash function, and reduces the result to a short decimal code, usually six digits. Both sides perform the same calculation independently: the service knows your secret and the time, your app knows your secret and the time, so they arrive at the same code without ever sending it to each other. That is why a TOTP code works offline: no network connection is needed, only a roughly correct clock.
The time step is what makes the code temporary. The standard step is 30 seconds, meaning the counter changes every 30 seconds and the code changes with it. A code is therefore valid only within its window, and services usually accept the current window plus one window either side to allow for clock drift and typing time. That tolerance is small by design: a code observed by an attacker is worthless within a minute or two, which is the whole security point. The six-digit length is a compromise between usability and security: 6 digits give 1,000,000 possible codes, and combined with a short validity window and a service that limits guessing attempts, that is enough, while longer codes would be harder to type correctly.
Setting up TOTP correctly matters more than understanding the mathematics. Scan the QR code with your authenticator app rather than typing the secret by hand, because a mistyped secret produces codes that never match and the failure gives no clue about which character was wrong. Save the recovery codes the service offers during setup, and store them somewhere separate from the device that holds the authenticator, such as printed on paper in a safe place, because losing the device without recovery codes can lock you out of the account entirely. If you change phones, transfer the authenticator entries before wiping the old device, or re-register each account on the new one. And keep the device clock automatic: a clock that drifts by more than a couple of minutes breaks TOTP silently, producing codes that look fine but are always rejected.
Security guidance for this topic is important, and it is worth stating plainly. Never paste a real secret key, a real recovery code, or a real one-time password into any web page, tool, message or screenshot unless you are certain the destination is the legitimate service and the action is one you intended. A demonstration tool should only ever be used with sample values, never with a secret that protects a real account, because anything typed into a page you do not fully control could be recorded. Treat any request for your current TOTP code with suspicion: legitimate support staff never ask for it, and a request for it is a classic phishing signal. The code is a second factor precisely because it is short-lived and private to you; sharing it defeats its purpose.
A worked example you can follow
Walk through the timing arithmetic with sample values only. Suppose a demonstration secret produces codes that change every 30 seconds. In one hour there are 3,600 seconds, so the number of distinct codes in that hour is 3,600 ÷ 30 = 120. In one day that becomes 120 × 24 = 2,880 codes. If an attacker guessed at random, the chance of hitting the current six-digit code in a single guess is 1 ÷ 1,000,000, and even 100 guesses within one 30-second window cover only 100 ÷ 1,000,000 = 0.0001, or one hundredth of one percent, of the space, before the window closes and every guess becomes worthless. Those numbers are why services can safely show a code on screen: the code's value expires faster than it can be brute-forced, provided the service also limits attempts.
Now trace a setup as a checklist rather than with real values. First, the service displays a QR code and a sample-style secret string; you scan it, and the app immediately shows a six-digit code with a countdown bar. Second, you type that code back into the service, which verifies it matches its own calculation for the current window. Third, you save the recovery codes the service shows, in a separate place. Fourth, you confirm the clock on your device is set automatically. If verification fails at step two, the usual causes are a mistyped secret, a clock more than a minute out, or a code typed after its window expired; waiting for the next code and retyping carefully resolves most failures without resetting anything.
Common mistakes to avoid
The most common mistake is storing the secret or recovery codes in the same place as the device, such as a screenshot on the phone that holds the authenticator, which defeats the separation two-factor relies on. A second mistake is entering a real secret into a demonstration or testing tool; use sample values only, and treat any tool that asks for a real secret as untrustworthy. A third mistake is ignoring clock drift, which produces a stream of plausible-looking codes that are always wrong. A fourth mistake is skipping the recovery codes, which turns a lost phone into a lost account. A fifth mistake is sharing a current code with anyone who asks, including someone claiming to be support; no legitimate support process needs your one-time code.
TOTP is one of the most effective security upgrades available for the effort it takes: one setup per account, then a few seconds per login. The code changes every 30 seconds, the secret never travels, and the account stays protected even when the password leaks.
Frequently asked questions
Why does my code change every 30 seconds? Because the code is derived from the current time in 30-second steps, so each window produces a new code and old codes expire automatically.
Why does a correct-looking code get rejected? Usually clock drift, a mistyped secret at setup, or the code's window expiring before you submitted it; check the clock first.
Should I use SMS codes instead? Authenticator-app codes are generally safer than SMS, which can be intercepted or redirected, but any second factor is far better than none.
For related security reading, see HTTP Security Headers Guide, and pair this generator, with sample values only, alongside the Password Generator and the Hash Generator when reviewing an account's security. Keep secrets private, save recovery codes separately, and never share a live code.