OTP

OTP (One-Time Password) is a single-use authentication code, typically 6 digits, that’s valid for a short window. Combined with a regular password it forms two-factor authentication (2FA).

Three common delivery channels:

• SMS OTP — code texted to the user’s phone. Most common, also least secure (SIM-swap attacks).
• TOTP (time-based, RFC 6238) — generated by an authenticator app from a shared secret + current time. No network needed. Common in Google Authenticator, Authy, 1Password.
• HOTP (counter-based, RFC 4226) — increments a counter per use. Now rare except for hardware tokens like YubiKey OTP mode.

OTPs defeat password reuse attacks (the stolen password alone is useless) but don’t defeat modern phishing — an attacker who phishes the OTP can replay it within the validity window. Hardware-key based (FIDO2 / WebAuthn) authentication does defeat phishing because the key proves it’s on the legitimate site.

The SMS-OTP downgrade problem: NIST’s 2017 SP 800-63B revision deprecated SMS as an out-of-band authenticator because of three documented attack patterns — SIM-swap fraud (the attacker convinces a mobile carrier to port the victim’s number to a new SIM), SS7 protocol exploits (the global telecom signalling network has weak authentication and can be queried to redirect texts), and physical-area number portability fraud. Banks and exchanges that fall back to SMS as a recovery method effectively reduce account security to whatever the mobile carrier’s customer-service script enforces. Apps that allow opting out of SMS in favour of TOTP-only or WebAuthn-only are meaningfully more secure.

TOTP mechanics — why the 30-second window: TOTP is HMAC-SHA1 of (shared secret, current 30-second timestamp), truncated to 6 digits. The 30-second granularity is a compromise: short enough to limit replay windows, long enough to forgive small clock skew between server and client. Most TOTP verifiers accept the previous, current, and next time-step values to handle ±30s skew, which is why the code that just expired in your authenticator often still works for a few seconds. Provisioning is done via a QR code that encodes otpauth://totp/Issuer:user?secret=...&period=30&digits=6. Related: TOTP, JWT. Reference: RFC 6238 — TOTP.

Worked example

You enrol in TOTP. The server generates a 160-bit secret (e.g. JBSWY3DPEHPK3PXP in base32), shows you a QR code, and your authenticator app stores the secret. To generate a code at the current Unix time 1716393600: compute the time-step T = floor(1716393600 / 30) = 57213120, then HMAC-SHA1(secret, T) produces a 20-byte hash. Dynamic-truncate per RFC 4226: take the last nibble of the hash as an offset, extract 4 bytes at that offset, mask the top bit, and modulo 10⁶ to get a 6-digit code — say 492039. The server does the same calculation; if the codes match (allowing one step on either side for clock skew), authentication succeeds. The whole protocol is deterministic and offline once the secret is provisioned.

When and why it matters

OTP is the difference between “the credential dump on the dark web compromises your account” and “the credential dump is useless without your phone.” Empirically, Google’s 2019 study with NYU and UCSD showed that adding any second factor blocked 99% of bulk credential-stuffing attacks; SMS OTP alone blocked 96% of targeted phishing and on-device prompts blocked 99%. The remaining gap — phishing kits that proxy OTPs in real time (Evilginx, Modlishka) — is closed only by phishing-resistant factors (WebAuthn/passkeys, FIDO2 hardware keys). The pragmatic ladder for any account: passwords-only → SMS OTP → TOTP authenticator app → hardware security key. Every step up materially raises the attacker’s cost. Reference: NIST SP 800-63B — Digital Identity Guidelines.