TOTP (Time-Based One-Time Password)
A time-synchronized one-time password algorithm (RFC 6238) that generates temporary authentication codes using HMAC and the current UNIX timestamp.
What is TOTP (Time-Based One-Time Password)?
TOTP (Time-Based One-Time Password) is a standardized algorithm defined in RFC 6238 that generates temporary, single-use authentication codes using a shared secret key and the current UNIX timestamp as input to an HMAC-based construction.
From a technical standpoint, TOTP is an extension of the HMAC-Based One-Time Password (HOTP) algorithm (RFC 4226), which replaces the moving counter with a time-based counter derived from the current time divided by a fixed time step.
Key technical characteristics:
- Algorithm: HOTP with time-based counter:
TOTP = HOTP(K, T)whereT = (currentUnixTime - T0) / X - Hash Function: HMAC-SHA1 (default), HMAC-SHA256, or HMAC-SHA512
- Code Length: Typically 6 digits, can be 7 or 8 digits
- Time Step (X): Default 30 seconds (configurable per RFC)
- Time Offset (T0): UNIX epoch (0), can be customized with a start time
- Drift Window: Servers typically allow ±1 time step to accommodate clock skew
In CIAM architectures, TOTP is the most widely deployed software-based second factor, supported by authenticator apps like Google Authenticator, Authy, Microsoft Authenticator, and 1Password.
Analogy
Think of TOTP like a synchronized watch that both you and the server share - at any given moment, the watch displays the same number, so you can prove you have the same watch without saying the code aloud.
Types and Use Cases
Types of TOTP Implementations:
- Standard 6-digit TOTP: Default configuration (SHA1, 30-second time step, 6-digit output) - used by Google Authenticator and most CIAM platforms
- TOTP with SHA256/SHA512: Enhanced hash functions for stronger security (less common due to backward compatibility requirements)
- Stepped TOTP (Dual Code): Applications display two concurrent codes to reduce urgency during time-step boundaries
- Biometric-Bound TOTP: TOTP secrets stored in device TPM/secure enclave, requiring biometric unlock to access
CIAM Use Cases:
- Consumer MFA Enrollment: Users scan QR code during account setup to register TOTP in their authenticator app
- Enterprise SSO Integration: TOTP as second factor for SAML/OIDC federated authentication
- Step-Up Authentication: Additional TOTP verification for password changes, payment authorization, or admin actions
- Offline Authentication: TOTP works without internet connectivity, making it ideal for travel and remote locations
- Compliance-Driven MFA: Meet regulatory requirements (SOC 2, ISO 27001, HIPAA, PSD2) with standardized TOTP verification
How it Works
import hmac
import hashlib
import struct
import time
def totp(secret: bytes, time_step: int = 30, digits: int = 6) -> str:
counter = int(time.time() // time_step)
msg = struct.pack('>Q', counter)
h = hmac.new(secret, msg, hashlib.sha1).digest()
offset = h[-1] & 0x0F
code = (struct.unpack('>I', h[offset:offset+4])[0] & 0x7FFFFFFF) % (10 ** digits)
return str(code).zfill(digits)
# Server-side validation with drift window
def verify_totp(secret: bytes, user_code: str, drift: int = 1) -> bool:
for i in range(-drift, drift + 1):
expected = totp(secret, time_step=30*(i+1))
if hmac.compare_digest(expected, user_code):
return True
return FalseTOTP (Time-Based One-Time Password) vs HOTP (HMAC-Based One-Time Password)
TOTP (Time-Based One-Time Password)
HOTP (HMAC-Based One-Time Password)
Counter Source: TOTP uses current UNIX timestamp divided by time step
HOTP uses an event counter incremented with each successful authentication
Resynchronization: TOTP handles drift automatically with ±1-2 time step validation windows
HOTP requires server to track and synchronize a counter value
Usability: TOTP codes change every 30 seconds regardless of use, reducing replay risk
HOTP codes remain valid until used, allowing pre-generation
Implementation Complexity: TOTP requires accurate time synchronization (NTP) on both client and server
HOTP requires no time sync but needs persistent counter state
Token Durability: TOTP tokens regenerate automatically every 30s, so stolen codes expire quickly
HOTP tokens remain valid until authenticated, creating longer exposure windows
Best Practices for TOTP (Time-Based One-Time Password)
CIAM Best Practices for TOTP:
- Use standard QR provisioning: Implement the otpauth:// URI format (key URI, issuer, account name) for seamless enrollment with all major authenticator apps
- Implement drift tolerance: Allow ±1 time step (90 seconds total window) to handle clock skew without compromising security
- Rate limit validation: Restrict to 3-5 failed attempts per session before requiring re-authentication to prevent brute force
- Monitor for token reuse: Log successful authentications with the exact time step used to detect token replay across sessions
- Provision backup codes: Generate 8-10 single-use recovery codes during TOTP enrollment for when user loses access to authenticator app
- Consider risk-based MFA: Only require TOTP for high-risk scenarios (new device, suspicious IP, sensitive actions) to reduce friction
How LoginRadius Powers TOTP (Time-Based One-Time Password)
LoginRadius CIAM platform provides comprehensive TOTP support implementing RFC 6238, enabling standardized time-based one-time password authentication for consumer and B2B identity scenarios.
Core Integration Capabilities:
- RFC 6238 Compliance: Full implementation of TOTP with HMAC-SHA1, configurable code length (6-8 digits), time step (15-60 seconds), and drift tolerance
- Universal Authenticator Compatibility: Supports Google Authenticator, Authy, Microsoft Authenticator, 1Password, Bitwarden, and all standards-compliant apps
- QR Code Enrollment: Automatic generation of otpauth:// URIs with issuer, account name, and secret encoded for QR display
- Self-Service Management: Users can enroll, view, and revoke TOTP authenticators from their security settings without admin intervention
Advanced CIAM Features:
- Recovery Codes: Generates 10 single-use backup codes during TOTP enrollment with secure storage and user-accessible display
- Multi-Instance Support: Users can register multiple TOTP authenticators (e.g., phone and tablet) simultaneously
- Risk-Based Authentication: Conditional TOTP requirement based on device trust, IP reputation, geolocation, and behavioral analytics
- Comprehensive Audit: Full audit trail of TOTP enrollment, usage, and recovery code redemption for SOC 2, HIPAA, and ISO 27001 compliance
Recommendation: Use TOTP as the standard MFA method for consumer-facing applications with broad adoption requirements. For enterprise and admin accounts, pair TOTP with FIDO2/WebAuthn hardware keys for phishing-resistant authentication at privilege boundaries.
FAQs
- Security Model: TOTP generates codes locally on the user's device with no network transmission of the secret; SMS OTP transmits the code over SS7 networks which can be intercepted
- SIM Swap Resistance: TOTP is immune to SIM swap attacks (the secret is stored in the authenticator app, not tied to phone number); SMS OTP is directly vulnerable
- Offline Capability: TOTP codes generate offline without internet or cellular connectivity; SMS OTP requires cellular network availability for delivery
- Cost: TOTP has zero per-verification cost after initial setup; SMS OTP incurs per-message costs ($0.0075-$0.10 each)
- NIST SP 800-63B: NIST approves TOTP for AAL2/AAL3 but deprecates SMS OTP for out-of-band verification
- Real-Time Phishing: Yes - TOTP codes can be phished via real-time relay attacks where a proxy captures the code and immediately uses it (evilginx, modlishka)
- Code Duration Risk: A TOTP code is valid for 30 seconds, limiting the window for replay but not eliminating it entirely
- One-Time Use: Most CIAM platforms enforce single-use semantics, but replay is possible if the attacker uses the code before the legitimate user
- Phishing Mitigation: FIDO2/WebAuthn is the only phish-resistant MFA method; TOTP should be paired with risk-based authentication to detect anomalous usage
- Best Defense: Implement FIDO2 as primary MFA for admin/high-value accounts, with TOTP as user-friendly fallback for consumer accounts
- Standard RFC 6238: LoginRadius implements TOTP per RFC 6238 with HMAC-SHA1, 6-digit codes, and 30-second time steps - fully compatible with Google Authenticator, Authy, and Microsoft Authenticator
- QR Enrollment: LoginRadius generates otpauth:// URIs rendered as QR codes for self-service MFA enrollment during user registration or from security settings
- Drift Configuration: Server-side time drift tolerance configurable from ±0 to ±3 time steps, with default ±1 step (90 seconds)
- Recovery Codes: LoginRadius automatically generates and displays 10 single-use backup codes during TOTP enrollment
- FIDO2 Hybrid: Recommend using LoginRadius's FIDO2/WebAuthn support as primary MFA with TOTP as fallback for maximum security and usability