Can an authenticator app stay perfectly synced with a remote server without ever sending a single message? Understanding the deterministic logic of TOTP is essential for IT teams moving away from insecure SMS. Here is how shared secrets and time windows generate secure, temporary authentication codes.
For IT professionals and MSPs, the one-time password (OTP) provides a highly resilient form of authentication. Unlike legacy protocols, the generated code never actually travels across the network until the moment of login, making it significantly harder for threat actors to intercept.
The Foundation of RFC 6238
TOTP is an open standard defined in RFC 6238. It is technically an extension of HOTP (HMAC-based One-Time Password), which uses a counter-based system. While HOTP increments a counter every time a code is requested, TOTP replaces that manual counter with a far more reliable variable: time.
Because time moves forward at the same rate for both the client authenticator and the server, both parties can calculate the exact same code at the exact same moment. This eliminates the need for constant communication or synchronisation messages, provided both devices have relatively accurate internal clocks.
The Two Core Inputs for Code Generation
To generate a valid code, the TOTP algorithm requires two specific inputs that must match on both the user's device and the authentication server.
The Shared Secret (The Seed)
When you first set up multi-factor authentication for an account, the service provides a secret key, often represented as a QR code. This key is a unique, random string of characters known as the "seed." The security of the entire system relies on this secret remaining private. If an attacker gains access to this seed, they can generate valid codes indefinitely for that account.
In professional environments, managing these seeds is a significant hurdle. Rather than leaving them on individual employee devices, sophisticated teams often use a shared OTP vault to maintain control and visibility over these critical secrets.
The Current Time (The Moving Factor)
The algorithm uses the current Unix time, which is the number of seconds elapsed since 1 January 1970. This time is divided by a time step, which is usually 30 seconds. This creates a "window" or "epoch" that serves as the dynamic component of the calculation. Every 30 seconds, the integer result of this division changes, triggering the generation of a new code.
From Hash to Human-Readable Code
The technical process follows a specific cryptographic path to ensure the resulting code is both short enough for a human to type and strong enough to resist brute-force attacks.
First, the algorithm applies a Keyed-Hashing for Message Authentication (HMAC), typically using the SHA-1 hash function. It hashes the current time step using the shared secret as the key. The resulting hash is a 20-byte string, which is far too long for a user to input manually.
To create a usable code, the algorithm performs "dynamic truncation" to extract a 4-byte binary value from the hash. Finally, it performs a modulo operation on that binary value (usually % 1,000,000) to produce a six-digit integer. This final product is the ephemeral code you see on your authenticator screen.
Managing Time Drift and Latency
One common concern for IT administrators is how the system handles slight variations in device clocks. If a user’s phone clock is five seconds ahead of the server’s, the login could potentially fail. To prevent this, most verifiers implement a validation window.
The server does not just check the current 30-second time step; it also checks the steps immediately before and after the current one. This grace period accounts for network latency and minor clock drift. However, to maintain security and adhere to NIST SP 800-63B standards, once a code is used, the server marks it as "spent" to prevent replay attacks.
Why TOTP Outperforms Legacy Methods
TOTP is fundamentally more secure than SMS-based MFA for several reasons that directly impact organisational security:
- No Interception: Because the code is generated locally using the shared secret and time, it is never sent over cellular networks where it could be intercepted via SIM swapping.
- Encrypted Storage: While SMS messages sit in a cleartext inbox, TOTP secrets can be stored in encrypted MFA management environments using AES-256.
- Ephemeral Nature: The 30-second window drastically limits the "window of exposure" compared to an SMS code that might remain valid for several minutes.
- Offline Functionality: Users can generate codes even without a cellular or internet connection, as the logic relies solely on the internal clock and the stored seed.
Implementing TOTP Across IT Teams
For MSPs and internal IT departments, the biggest risk with TOTP isn't the algorithm itself, but the management of the shared secrets. When these seeds are stored on a single technician's smartphone, the organisation faces significant operational bottlenecks and security gaps during employee offboarding.
Professional teams transition these secrets into a centralised MFA vault for teams. This allows you to centralise the seeds, enforce granular access controls, and maintain detailed audit logs of who accessed which code and when. This approach ensures that your security infrastructure remains robust and compliant without being tied to individual personal devices.
If you are ready to move your team’s MFA codes off personal devices and into a secure, collaborative environment, you can start a 14-day free trial with Gatera today – no credit card required.