What TOTP is
TOTP (time-based one-time password) is simple: the server and your authenticator app share a seed secret, and both compute the same 6-digit code from "current time step (usually 30s) + HMAC-SHA1". The server just checks for a match.
What it actually defends against
2FA defends against password leaks and credential stuffing: an attacker with your password still cannot produce the next code without the seed. It does not defend against live phishing — a man-in-the-middle can forward your freshly typed code to the real site immediately.
Three tiers of 2FA strength
| Method | Strength | Weakness |
|---|---|---|
| SMS code | Weak | SIM swap, signal interception, carrier insiders |
| TOTP app | Medium | Not domain-bound, easy to relay in live phishing |
| Hardware key / Passkey (WebAuthn) | Strong | Domain-bound, phishing can't replay it; needs device support |
How to use it well
- Priority: hardware key or Passkey first, then a TOTP app; SMS only as a last resort;
- Keep recovery codes: print or store them in a password manager so you are not locked out if you lose your phone;
- Store separately: don't keep the TOTP seed next to the password (avoid one cloud sync holding both);
- Check the clock: if verification fails, confirm device time is accurate — drift breaks the code.
Seed secret and QR code
The QR code at setup is an otpauth:// link with a Base32-encoded seed. Screenshotting it leaks the seed; use an authenticator that supports encrypted export.
Try it
Generate a strong random seed: Password generator, Hashing.
TOTP in practice
The core algorithm is simple — shared secret plus a time-step HMAC — but the engineering details decide the security:
- Secret requirements: at least 160 random bits shown to the user as Base32; display it once at enrolment, store it encrypted and never read it back in clear;
- Time alignment: accept one step either side (three 30-second windows) to tolerate clock drift, but do not widen it further;
- Replay protection: a given 6-digit code may succeed only once within its window, so record used counter values;
- Rate limiting: six digits is only a million combinations — cap consecutive failures and lock or cool down, or it can be brute-forced online;
- Recovery codes: give users one-time codes, stored hashed and invalidated after use, plus a path to unbind and re-enrol.
Common misconceptions
- SMS as a second factor: interceptable or SIM-swapped, materially weaker than TOTP;
- Treating the QR code as the secret: it is only a transport format — the secret still needs encrypted storage;
- Assuming "2FA means safe": if a login page can be reverse-proxied in real time, TOTP can be relayed too; high-value flows should move to WebAuthn;
- Validating on the client: verification must happen entirely server-side.
Choosing among second factors
Roughly in anti-phishing order: WebAuthn (hardware keys or platform authenticators) beats TOTP, TOTP beats push confirmation, and SMS is weakest. Weigh device availability and support cost when choosing.
Handling client clock drift
- Accept adjacent windows: one step either side covers most device drift while keeping the valid span at 90 seconds;
- Watch for skew: if most users validate on the same off-centre window, clients are systematically fast or slow, or server time is off;
- Sync the clock: run NTP on the server — clock drift breaks the whole verification scheme;
- Recovery codes as a fallback: when clocks are badly wrong, one-time codes are the only dependable escape hatch.
Pre-launch checklist
- Secrets stored encrypted and never readable in clear;
- Adjacent windows accepted and NTP enabled on the server;
- A given code can succeed only once (replay protection);
- Failed attempts lock or cool down, with recovery codes and an unbind path available.