The Two Core OTP Standards
When you set up an authenticator app or implement OTP in an application, you're almost certainly dealing with one of two standards: TOTP (Time-based One-Time Password) or HOTP (HMAC-based One-Time Password). Both are built on the same cryptographic foundation — HMAC-SHA1 — but they differ in how they introduce uniqueness into each code.
How HOTP Works
HOTP is defined in RFC 4226 and was the original OTP standard. It generates a code by combining:
- A shared secret key known to both the client and server
- A counter value that increments with each authentication attempt
Both the authenticator and the server keep track of this counter independently. When you press "generate" on an HOTP device, the counter increments and a new code is produced. The server validates the code by checking the expected counter window.
Key characteristic: HOTP codes do not expire based on time — they remain valid until used or until too many unused codes have been skipped (look-ahead window).
How TOTP Works
TOTP is defined in RFC 6238 and extends HOTP by replacing the counter with a time-derived value. Specifically, it uses:
- The same shared secret key
- The current Unix timestamp divided into fixed time steps (commonly 30 seconds)
Because both sides use synchronized clocks, no counter needs to be tracked. The server simply computes the expected code for the current time window and compares it to what the user submitted — usually accepting one step before and after to accommodate minor clock drift.
Key characteristic: TOTP codes expire automatically, typically every 30 seconds.
Side-by-Side Comparison
| Aspect | HOTP | TOTP |
|---|---|---|
| RFC Standard | RFC 4226 | RFC 6238 |
| Uniqueness factor | Counter | Time (Unix timestamp) |
| Code expiry | No automatic expiry | Every 30–60 seconds |
| Clock sync required | No | Yes (minor drift tolerated) |
| State to maintain | Counter value | None (just the secret) |
| Replay attack risk | Higher if not used promptly | Lower (short validity window) |
| Common use cases | Hardware tokens, offline devices | Authenticator apps, most 2FA |
Security Considerations
HOTP Security
Because HOTP codes don't expire by time, a code intercepted but not immediately used is still valid until the counter advances past it. This extends the window of vulnerability. Implementations should enforce a strict look-ahead window (e.g., 5–10 codes) to limit this exposure and invalidate used codes immediately.
TOTP Security
TOTP's automatic expiry significantly shrinks the attack window. Even if an attacker captures a TOTP code, they have at most 30 seconds to use it. This makes TOTP the preferred choice for most consumer-facing 2FA implementations today. The main risk is phishing — a user can be tricked into entering a valid TOTP code on a fake site in real time.
When to Use HOTP
- Hardware security tokens that may not always be connected or online
- Scenarios where clock synchronization is impractical or unreliable
- Batch code generation for one-time use vouchers or scratch codes
When to Use TOTP
- Mobile authenticator apps (Google Authenticator, Authy, Microsoft Authenticator)
- Any consumer-facing 2FA where users have smartphones
- Most modern web applications and APIs requiring step-up authentication
Summary
For the vast majority of modern use cases, TOTP is the better choice due to its short-lived codes and simpler server-side state management. HOTP remains relevant for specialized hardware devices or offline environments. Understanding which standard your system uses helps you configure it correctly and troubleshoot sync issues when they arise.