TOTP / 2FA Code Generator

TOTP (Time-based One-Time Password) is the standard powering almost every "scan this QR code into your authenticator app" two-factor authentication flow on the modern web. Specified in RFC 6238 in 2011, it generates a fresh 6-digit code every 30 seconds from a shared secret known only to the user's authenticator app and the service's server. The codes are deterministic given the same secret and the same time — meaning Google's server and your Google Authenticator app independently compute the same digit string, without ever exchanging the code itself over the network. Loss of network connectivity does not break TOTP; only loss of clock sync does.

The algorithm in one paragraph

TOTP is HOTP (HMAC-based One-Time Password, RFC 4226) with the counter replaced by floor(unix_time / 30). The server and client both compute HMAC-SHA1 over that counter using the shared secret, then take the last byte of the HMAC output, mask off the high bit, and use the result as an offset to extract 4 bytes from the HMAC. Those 4 bytes are interpreted as a 31-bit integer modulo 10⁶ to produce the 6-digit code. The entire computation is around 20 lines of JavaScript when SubtleCrypto handles the HMAC primitive for you. The current standard supports SHA-1, SHA-256, and SHA-512 variants; SHA-1 remains the default for compatibility with older authenticator apps.

Drift tolerance and the 30-second window

Real-world clocks aren't perfectly synchronised. A phone's clock might be a few seconds ahead or behind the server. A user might also start typing a code with 28 seconds left on the timer and finish typing 5 seconds after the window rolled over. To handle these, RFC 6238 recommends accepting codes from the immediately-previous and immediately-next 30-second windows as well as the current one. Most major services (Google, AWS, Microsoft 365, GitHub) implement this drift tolerance of ±1 window — giving an effective 90-second acceptance band. Some banking and high-security services tighten this to ±0 (current window only) or use ±2 (150-second band) depending on their risk model.

Why MAS and BNM mandates matter for ASEAN fintech

Singapore's Monetary Authority (MAS) requires two-factor authentication for retail banking and licensed payment services under MAS Notice 644 and the Technology Risk Management Guidelines. Malaysia's Bank Negara has equivalent requirements via the eKYC and RMiT (Risk Management in Technology) guidelines. Both regulators accept TOTP via authenticator apps as a compliant second factor — alongside SMS-OTP and hardware tokens. Singapore's Singpass MFA architecture uses a custom proprietary scheme, but most ASEAN consumer-fintech and e-wallet products (GrabPay, ShopeePay, Touch 'n Go) rely on TOTP behind the scenes for their backend service authentication, even when the consumer-facing factor is biometric or SMS-OTP.

What this tool is not

This is a learning / testing / integration-verification tool. It is not a production authenticator app. Paste a Google account's TOTP secret into this page and you have effectively stored that secret in your browser's tab memory — accessible to any browser extension with content-script permission, any cross-site-scripting vulnerability on any other page in the same browser session, and any malware capturing the page's DOM. For real accounts, use a dedicated authenticator app (Google Authenticator, Authy, 1Password, Bitwarden's built-in TOTP) or a hardware key (YubiKey). The tool above is for verifying that your server's TOTP implementation produces codes matching what the standard authenticator app would produce — a debugging tool, nothing more.