Time-based one-time passwords as a second factor

What it is

RFC 6238 defines TOTP as HOTP (an HMAC over a counter) where the counter is the number of 30-second steps since the Unix epoch; the result is truncated to six or eight digits. Authenticator apps and the server share the secret; the server verifies by computing the code for the current step and a small window around it.

Why it matters

A second factor stops attackers who only have the password. TOTP is cheap and offline. It does not stop an attacker who relays the code in real time (phishing), which is why phishing-resistant methods (passkeys) are preferred for high-value accounts.

How to apply

• Generate the secret with a cryptographic random source and store it encrypted or in a secrets store; it is as sensitive as a password.
• Accept one step of clock drift each way at most; rate-limit verification attempts and reject a code that was already used.
• Provide single-use recovery codes at enrolment, stored hashed.
• Require the second factor for sensitive actions, not only at login.

Pitfalls

Sending the secret or QR code over insecure channels. Allowing enrolment without re-authentication. Treating SMS codes as equivalent; they are weaker. Time skew on the server breaks all users at once; keep clocks synchronised.

What it is

RFC 6238 defines TOTP as HOTP (an HMAC over a counter) where the counter is the number of 30-second steps since the Unix epoch; the result is truncated to six or eight digits. Authenticator apps and the server share the secret; the server verifies by computing the code for the current step and a small window around it.

Why it matters

A second factor stops attackers who only have the password. TOTP is cheap and offline. It does not stop an attacker who relays the code in real time (phishing), which is why phishing-resistant methods (passkeys) are preferred for high-value accounts.

How to apply

• Generate the secret with a cryptographic random source and store it encrypted or in a secrets store; it is as sensitive as a password.
• Accept one step of clock drift each way at most; rate-limit verification attempts and reject a code that was already used.
• Provide single-use recovery codes at enrolment, stored hashed.
• Require the second factor for sensitive actions, not only at login.

Pitfalls

Sending the secret or QR code over insecure channels. Allowing enrolment without re-authentication. Treating SMS codes as equivalent; they are weaker. Time skew on the server breaks all users at once; keep clocks synchronised.

Limits: TOTP is phishable

A fraudulent login page can relay a TOTP code to the real site within its validity window, so TOTP does not protect against real-time phishing. Where phishing is in the threat model, offer WebAuthn/passkeys as the primary second factor and keep TOTP as a fallback; rate-limit code attempts and invalidate a code after successful use.