Category: Multi-Factor Methods

Time-Based One-Time Password

Also known as: TOTP, time-based one-time password, time-based OTP

Simply put

A Time-Based One-Time Password (TOTP) is a temporary numeric code used to help verify a user's identity during login. The code is generated from a secret shared between the user's device or app and the service, combined with the current time, so it changes at regular intervals (commonly every 30 seconds). Because each code is short-lived, it provides better protection than a static password even if a code is intercepted.

Formal definition

TOTP is an algorithm that generates a short-lived one-time password (OTP) from a shared secret key and the current time as the source of uniqueness, defined by RFC 6238. In typical deployments, the authenticator (for example a mobile app such as Google Authenticator) and the verifying server hold the same shared secret and independently compute the OTP for the current time step (often a 30-second window), authenticating the user when the values match; servers commonly permit a small tolerance for clock drift depending on configuration. As an authentication mechanism, TOTP represents a possession factor, the holder of the seeded device or app, and is frequently used as a second factor within MFA. Scope note: TOTP addresses authentication (verifying identity) only and does not by itself address authorization; the strength of the shared-secret model and its resistance to phishing differ from cryptographic protocols such as FIDO2/WebAuthn, which are out of scope for this term.

Why it matters

TOTP is one of the most widely deployed second factors in multi-factor authentication because it raises the cost of credential-based attacks without requiring specialized hardware. A static password, once phished or leaked, can be reused indefinitely; a TOTP code is valid only for a short time step (commonly 30 seconds), so an intercepted or reused code typically expires quickly. This short lifespan is the core value: it narrows the window in which a stolen code is useful and adds a possession factor on top of the knowledge factor a password represents.

At the same time, IAM teams should be precise about what TOTP does and does not protect against. Because verification depends on a shared secret held by both the authenticator and the server, TOTP does not provide the cryptographic, origin-bound protection of protocols such as FIDO2/WebAuthn (which are out of scope for this term). A user can still be induced to enter a valid code into a fraudulent site or relay it to an attacker in real time, so TOTP is more resistant to password replay than to real-time phishing and social-engineering attacks. Its shared-secret model also means the seed must be protected during enrollment and at rest on both endpoints.

Understanding these boundaries matters when choosing where TOTP fits in an authentication strategy. In many deployments it is a pragmatic, low-friction improvement over passwords alone, but its assurance level should be weighed against phishing-resistant alternatives depending on the risk profile of the resource being protected.

Who it's relevant to

IAM Engineers and Architects

Those designing authentication flows use TOTP as a possession-factor option within MFA, typically layered on top of a password. They must account for shared-secret enrollment, secure seed storage, clock-drift tolerance, and the fact that TOTP is more resistant to replay than to real-time phishing when deciding where it is an appropriate assurance level.

System Administrators

Administrators enroll users, provision authenticator apps, and troubleshoot failed verifications that often stem from clock synchronization or seed mismatch. Understanding the 30-second time step and the server's drift tolerance helps them diagnose why an otherwise valid code may be rejected.

Security and Compliance Leads

For teams evaluating authentication controls, TOTP represents a common step up from passwords alone, but its shared-secret model and susceptibility to real-time phishing should be documented when comparing it against phishing-resistant alternatives such as FIDO2/WebAuthn for higher-risk resources.

Inside TOTP

Shared secret

A symmetric key provisioned to both the authenticator (typically a mobile app or hardware token) and the verifying server, commonly delivered during enrollment via a QR code encoding an otpauth URI. Because the secret is shared, both parties can independently compute the same code.

Time step (time counter)

TOTP derives a moving factor by dividing the current Unix time by a fixed time step, typically 30 seconds in most deployments. The resulting counter value feeds the underlying HOTP computation, so the code changes as each interval elapses.

HMAC computation

TOTP is built on the HOTP construction, applying an HMAC (commonly HMAC-SHA1 by default, though SHA-256 or SHA-512 may be configured) over the shared secret and the time counter, then truncating the result to produce the displayed code.

One-time passcode

The truncated, typically 6-digit (sometimes 8-digit) numeric code presented to the user and submitted as a possession-factor proof. It is valid only for the current time step and any accepted validation window.

Validation window

To tolerate clock drift and transmission delay, verifiers typically accept codes from one or more adjacent time steps in addition to the current one. The width of this window is a configuration trade-off between usability and exposure.

Common questions

Answers to the questions practitioners most commonly ask about TOTP.

Is TOTP a form of multi-factor authentication on its own?

No. TOTP is a single authentication factor, specifically a possession factor, since it proves control of the shared secret typically stored on an enrolled device or authenticator app. It becomes part of MFA (or 2FA) only when combined with a factor of a different type, such as a knowledge factor (a password) or an inherence factor (a biometric). Using TOTP by itself is single-factor authentication, and stacking it with another possession factor does not satisfy the different-factor-type requirement most policies expect.

Does TOTP verify what a user is allowed to do, or just who they are?

TOTP contributes only to authentication, verifying that the presenting party controls the enrolled secret. It says nothing about authorization, which is the separate step of determining what the authenticated principal may access. In a typical access flow, identification and authentication (which TOTP may participate in) precede authorization, and TOTP should not be treated as an access-control mechanism.

How is the shared secret provisioned to a user's authenticator app?

In most deployments the server generates a secret and delivers it to the authenticator during enrollment, commonly encoded in a QR code (following the otpauth URI convention widely used by authenticator apps) or shown as a manual entry string. Because both the server and the authenticator must hold the same secret, secure enrollment and confidential transport are important; the specific delivery format and any additional protections depend on the implementation and vendor.

How does TOTP handle clock differences between the server and the user's device?

TOTP derives codes from the current time divided into fixed intervals, so the server and authenticator must be roughly time-synchronized. To tolerate small drift and transmission delay, most server implementations accept codes from one or more adjacent time steps (a validation window). Widening this window increases usability but expands the interval during which a given code is valid, so the size is a configuration trade-off that varies by deployment.

What should be done to prevent reuse of a TOTP code within its validity window?

Because a code can remain valid across its time step and any accepted adjacent steps, many implementations track recently consumed codes per user and reject a code that has already been used, mitigating replay within the window. Whether this protection is enforced depends on the implementation; where it is not present, an intercepted code may be reusable until its window expires.

How are backup or recovery options typically handled for TOTP enrollment?

Since TOTP depends on possession of the enrolled secret, loss of the device can lock a user out. Deployments commonly address this with recovery mechanisms such as pre-generated backup codes, enrollment of a secondary authenticator, or an administrative re-enrollment process. The available options and their security posture vary by vendor and configuration, and recovery flows themselves should be protected to avoid becoming a weaker authentication path.

Common misconceptions

TOTP is an authentication protocol comparable to SAML or OIDC.

TOTP is an algorithm for generating a possession-based one-time credential, not a federation or authentication protocol. It is typically used as one factor within an authentication flow, and it does not by itself convey identity assertions or tokens the way OIDC or SAML do.

TOTP codes are transmitted from the server to the device like SMS OTPs.

In most deployments TOTP codes are computed locally on both the authenticator and the verifier from the shared secret and current time, so no code is sent over a channel. Only the initial shared secret is exchanged during enrollment.

TOTP provides phishing-resistant authentication.

TOTP is generally susceptible to real-time phishing and relay attacks because a user can be induced to enter a valid code on an attacker-controlled site. Origin-bound methods such as WebAuthn/FIDO2 are typically needed where phishing resistance is a requirement; this is out of scope for what TOTP alone provides.

Best practices

Protect the shared secret at rest on the verifier side, encrypting stored seeds and restricting access, since compromise of the secret allows an attacker to generate valid codes independently.

Keep the validation window as narrow as clock-synchronization tolerances allow, and ensure server time is reliably synchronized (for example via NTP) to minimize both false rejects and the acceptance window an attacker could exploit.

Enforce single-use semantics by rejecting a code that has already been accepted within its validity window to reduce replay exposure.

Apply rate limiting and lockout on TOTP verification attempts to mitigate brute-force guessing of the limited code space.

Treat TOTP as one possession factor combined with a distinct knowledge or inherence factor rather than as standalone authentication, and consider stronger origin-bound methods where phishing resistance is required.

Deliver enrollment secrets over a secure channel, verify the initial code before activating the factor, and provide a controlled re-enrollment and recovery path for lost or replaced authenticators.