MFA and One-Time Password Overview
Multi-Factor Authentication (MFA) provides defense-in-depth when passwords are compromised by requiring users to provide two or more mutually independent authentication factors to prove identity. This chapter focuses on the most common second factor in engineering practice—One-Time Password (OTP)—with emphasis on the HOTP and TOTP algorithms.
What is MFA
The core weakness of single-password authentication is that passwords are static and reproducible credentials. Once compromised via password databases, phishing, data breaches, or keyloggers, attackers can replay them indefinitely. MFA's approach is to layer authentication factors from different "categories," forcing attackers to compromise multiple independent channels simultaneously.
Three Categories of Authentication Factors
Authentication factors are traditionally divided into three categories. MFA requires factors from different categories to constitute true "multi-factor" (two passwords do not constitute MFA):
| Category | English | Meaning | Typical Examples |
|---|---|---|---|
| Knowledge | something you know | Secrets memorized by the user | Password, PIN, security questions |
| Possession | something you have | Device or object owned by the user | TOTP authenticator app, hardware token, phone (SMS/push), FIDO security key |
| Inherence | something you are | Biometric trait of the user | Fingerprint, face, iris, voiceprint |
Tips
"Knowledge + Possession" is the most mainstream MFA combination: password (knowledge) + TOTP authenticator app (possession). The OTP discussed in this chapter belongs to the "possession" category—it proves the user possesses the device that stores the shared secret.
What Problem Does OTP Solve
One-Time Password (OTP) is a dynamic passcode that can only be used once and quickly expires. Compared to static passwords, its value lies in:
- Replay resistance: Each OTP is valid for only a very short window (TOTP typically 30 seconds), so even if intercepted, the attacker's window for reuse is minimal.
- Unpredictability: OTP is generated by a cryptographic algorithm based on a shared secret, making it impossible for attackers to predict the next OTP from historical ones.
- Offline generation: Computed from the local shared secret without network round-trips, not dependent on SMS channels (SMS OTP has SIM hijacking and other risks).
OTP has two standard algorithms, both defined by the IETF and sharing the same dynamic truncation core:
- HOTP (HMAC-based One-Time Password, RFC 4226): Based on an incrementing counter.
- TOTP (Time-based One-Time Password, RFC 6238): Based on current time, a time-based variant of HOTP.
Relationship and Differences Between HOTP and TOTP
TOTP is not an independent algorithm but rather HOTP with the "counter" replaced by "time step." Their relationship can be summarized as:
TOTP(K) = HOTP(K, T), where T = floor((current Unix time - T0) / period)
In other words, HOTP is the foundation, and TOTP is a modification where the moving factor changes from "counter" to "time slice number."
| Dimension | HOTP (RFC 4226) | TOTP (RFC 6238) |
|---|---|---|
| Moving factor | Event counter | Time step T |
| When it changes | Counter increments by 1 on each generation | Automatically changes at each time step (default 30 seconds) |
| Server-side state | Must persist and sync counter | Only needs to store the key, no counter needed |
| Desynchronization risk | Client and server counters may drift, requires look-ahead window | Only affected by clock offset |
| Validity period | Valid until the next use | Valid only in current time step (+ tolerance window) |
| Typical use case | Hardware token key generation, offline scenarios | Authenticator app, vast majority of online MFA |
Warning
HOTP counter synchronization is an engineering challenge: users may accidentally advance the token counter, and the server must set a "look-ahead window." TOTP replaces the counter with time, naturally avoiding this issue, which is why almost all online services use TOTP.
TOTP's Position in Practice
TOTP is the most widely deployed software second factor:
- Authenticator apps: Google Authenticator, Microsoft Authenticator, Authy, 1Password, FreeOTP, etc. all implement TOTP via QR code import of the shared secret.
- Login integration: In enterprise login flows using OIDC (OpenID Connect) / SAML, TOTP commonly serves as a second verification step after passwords (step-up / second factor), triggered by the IdP (Identity Provider) after the first factor.
- Standardization and interoperability: Because both the algorithm and the
otpauth://URI have public standards, any authenticator app and any server can interoperate without vendor lock-in.
Comparison with WebAuthn
TOTP is simple to deploy and offers familiar UX, but it has a fundamental limitation: it is not phishing-resistant. TOTP codes have no binding to the domain being accessed, so users will enter the 6-digit code seen on a phishing site as-is, and attackers can relay it in real-time (real-time phishing / MITM). WebAuthn / FIDO2 uses public-key cryptography and binds credentials to the origin domain, preventing phishing at the protocol level.
| Feature | TOTP | WebAuthn / Passkey |
|---|---|---|
| Phishing resistance | No (codes can be relayed) | Yes (credentials bound to origin) |
| Shared secret | Yes (server also stores key; compromise enables cloning) | No (private key never leaves device) |
| Breach resilience | Weak | Strong (server only stores public key) |
| User action | Manually enter 6-digit code | Biometric/PIN one-touch |
| Deployment cost | Low | Medium (requires browser/platform support) |
| Offline usability | Yes | Varies by authenticator |
Tips
Think of TOTP as a "middle layer—stronger than passwords, weaker than WebAuthn." For high-security requirements, prioritize WebAuthn adoption (see ../webauthn/); TOTP is suitable as a baseline second factor with broad coverage, or as a fallback when WebAuthn is unavailable.
Applicable Scenarios
- Recommended for TOTP: Public-facing SaaS needing a zero-hardware-cost, cross-platform second factor; enterprises rolling out MFA to existing accounts; fallback for WebAuthn.
- Recommended for HOTP: Distributing dedicated hardware tokens, offline devices without stable clocks.
- Caution/not recommended: Using SMS OTP alone as the sole second factor for high-value accounts (SIM hijacking, SS7 attack risks); scenarios with hard requirements for phishing resistance should use WebAuthn.
Navigation for This Chapter
- HOTP / TOTP Algorithm Deep Dive — Shared secrets, HMAC dynamic truncation, TOTP time steps, verification windows, and complete JS example.
- otpauth URI and Parameter Reference —
otpauth://URI format, parameter defaults, QR code conventions, authenticator compatibility, and troubleshooting reference.