TOTP one-time codes

Your authenticator app and the website never talk during sign-in, yet both come up with the same six digits. They simply agree on the time.

The short answer

TOTP (Time-Based One-Time Password) is an algorithm that turns a shared secret and the current time into a short code, by default valid for 30 seconds [1]. It is the time-based form of HOTP, which uses a counter instead [1][2]. Authenticator apps use it as a second factor: the app and the server each calculate the code on their own and compare [4][5]. Our assessment: TOTP is a good second factor, but a fake login page can still collect the code, so passkeys are the stronger choice where available [4].

How it works

1. The shared secret. When you enable TOTP, the site shows a QR code that carries the secret. It is usually a URI of the form otpauth://totp/Label?secret=…&issuer=…. The secret is Base32-encoded, and the optional parameters have defaults: SHA1, 6 digits, a 30-second period [3]. Treat this secret like a password.
2. The calculation. TOTP is defined as HOTP(K, T), where T counts time steps since the Unix epoch: T = (current Unix time − T0) / X, with the default X = 30 seconds and T0 = 0 [1]. HOTP runs HMAC-SHA-1 over the secret and the counter and truncates the result to a short number, at least 6 digits [2]. TOTP may also use HMAC-SHA-256 or HMAC-SHA-512 [1].
3. The check. The server computes the code for the same time step and compares. Because network delay can push a code into the next step, a server should accept a small window, and RFC 6238 recommends at most one time step of delay [1]. Your device clock therefore needs to be close to the real time.
4. Why the window is small. A larger window gives an attacker more time. OWASP's table assumes 10 guesses per second with no rate limit: about 58% success after 24 hours if one code is valid, and 92% if three are [5]. Servers need attempt limits, and OWASP asks for strict ones [4].
5. Where TOTP is weak. The secret exists on both the server and your device. OWASP lists phones that get compromised, backup seeds stored insecurely, and lockout when the phone is lost. It also lists phishing, although codes are short-lived [4]. Attackers use reverse-proxy tools that relay your code in real time, and phishing-resistant authenticators bind the sign-in to the real origin [4].

A practical example

The RFC's own example: with T0 = 0 and X = 30, T is 1 at Unix time 59 seconds and 2 at 60 seconds, so the code changes at that second [1]. A provisioning link from Google's key URI documentation looks like this [3]:

otpauth://totp/Example:alice@google.com?secret=JBSWY3DPEHPK3PXP&issuer=Example

Everyone who sees that secret can generate your codes, so a real one never belongs in a chat, a screenshot or a repo. The key URI format is a de-facto convention from Google's wiki and not an RFC, although an individual Internet-Draft, first published in 2024, tries to document it [3][6]. Its latest version, -03 of 24 Aug 2026, is still an individual draft with no formal standing in the IETF standards process [6].

Checklist

• Choose a passkey or hardware key over TOTP when a site offers one [4].
• Scan the QR code only on the site's own security settings page.
• Save the recovery codes when you enable TOTP, and keep them offline [5].
• Back up the secrets or add a second authenticator device during setup, because a lost phone locks you out [4].
• Keep the device clock synchronised with network time.
• Never type a code into a page you reached from a message link.