Generate 2FA TOTP authentication codes online from a shared secret key. Keep track of code expiration intervals.
The Time-based One-Time Password (TOTP) algorithm is an extension of the HMAC-based One-Time Password (HOTP) standard. While HOTP relies on a counter that increments with every request, TOTP replaces this counter with a time-based value. Specifically, it utilizes the Unix epoch time divided by a predefined time step (typically 30 seconds) to ensure that the resulting token is valid only for a narrow window of time.
This tool implements the RFC 6238 specification. The process begins by taking a shared secret key, which is typically encoded in Base32. This secret is decoded into a byte array and used as the key for an HMAC-SHA1 hashing operation. The input to this hash is the current time step. The resulting 20-byte HMAC hash is then truncated to a 6-digit integer through a process called Dynamic Truncation, ensuring the output is human-readable yet cryptographically secure.
Our generator provides a high-precision implementation of the TOTP flow, offering the following technical capabilities:
Developers can integrate TOTP logic into their own applications to build custom 2FA systems. Below is a practical implementation using Python and the pyotp library, which mirrors the logic used in this tool:
import pyotp
# Define the shared secret key (Base32)
secret = 'JBSWY3DPEHPK3PXP'
# Initialize the TOTP object
totp = pyotp.TOTP(secret)
# Generate the current 6-digit code
print(f'Current TOTP: {totp.now()}')For those working in Node.js, the otplib package is the industry standard. The process involves initializing the authenticator with the secret and calling the generate method to produce a time-synced token.
This usually occurs due to clock drift between your local device and the authentication server. Since TOTP relies on the Unix epoch time, a difference of even 30 seconds can move the token into a different time window. Most professional servers implement a 'look-ahead' or 'look-behind' window, accepting tokens from the previous or next interval to mitigate this synchronization issue.
Yes, Base32 is the standard encoding for TOTP secrets because it excludes visually ambiguous characters (like 0, 1, O, and I), making it easier for humans to transcribe keys manually. The algorithm requires the raw bytes of the secret; Base32 serves as the transport mechanism to ensure those bytes remain intact and readable across different systems.
While SHA-1 is considered weak against collision attacks in digital signatures, it remains highly effective for TOTP. In this specific application, the HMAC construction prevents the types of attacks that compromise SHA-1 in other contexts. The security of the TOTP system relies more heavily on the secrecy and entropy of the shared key than on the collision resistance of the hash function.
Yes, the RFC 6238 specification allows for variable token lengths. To achieve 8 digits, the dynamic truncation process is modified to perform a modulo 10^8 operation instead of 10^6. However, this requires both the generator and the verifying server to be configured for 8 digits, otherwise, the authentication will fail.
If a shared secret is leaked, an attacker can generate valid TOTP tokens indefinitely for that account. Because the secret is the only piece of static data used in the calculation, the security is entirely dependent on its confidentiality. In the event of a compromise, the secret must be revoked immediately and a new key pair must be generated and distributed.