TOTP vs HOTP: Two Approaches to One-Time Passwords

TOTP and HOTP generate one-time passwords, but they use different mechanisms

Both TOTP and HOTP are open standards for generating one-time passwords (OTPs). They share the same core algorithm but use a different synchronisation mechanism. Understanding both helps you choose the right implementation and appreciate why TOTP became dominant.

The Shared Foundation: HMAC-Based OTP

Both standards build on HOTP (RFC 4226), which is the base algorithm. The formula:

HOTP(secret, counter) = Truncate(HMAC-SHA1(secret, counter)) mod 10^digits

The only difference between TOTP and HOTP is what goes into the counter parameter:

  • HOTP: A monotonically increasing integer counter
  • TOTP: The current Unix timestamp divided by the time period (30 seconds)

How HOTP Works

HOTP (HMAC-based One-Time Password, RFC 4226) uses a shared counter that increments with each authentication:

  1. Both client and server start with counter = 0
  2. Client generates a code using HMAC-SHA1(secret, counter)
  3. Client increments the counter by 1
  4. Server verifies the code, then also increments the counter
  5. Both stay in sync as long as neither misses a step

HOTP Strengths

  • No time synchronisation is needed  works on devices with no accurate clock
  • Codes don't expire  useful for hardware tokens with no display (the code generates on button press)
  • Works offline indefinitely  hardware tokens with a battery can generate codes for years

HOTP Weaknesses

  • Counter desynchronisation: If the client generates codes without submitting them (e.g., accidentally presses the hardware token button), the client and server counters drift out of sync. Servers typically allow a "look-ahead window," but this reduces security.
  • Codes are valid until used: An HOTP code doesn't expire. If an attacker intercepts a code, they can use it any time in the future until the counter advances past that point.
  • Replay window: The server can't know if the same code was used twice if the counter hasn't advanced yet.

How TOTP Works

TOTP (Time-Based One-Time Password, RFC 6238) extends HOTP by replacing the counter with a time value:

T = floor(current_unix_timestamp / 30)  // time step
TOTP(secret) = HOTP(secret, T)

The 30-second window means:

  • A new code is generated every 30 seconds
  • Client and server agree on the current code because they share a clock
  • No counter state to synchronise clocks do the synchronisation automatically

TOTP Strengths

  • Codes expire automatically 30-second validity window minimises replay attack risk
  • Self-synchronising  no counter drift, clocks are accurate enough on modern devices
  • No state on the token  lost tokens can be replaced without counter re-sync
  • Uniform validity: All codes have the same 30-second lifetime regardless of usage

TOTP Weaknesses

  • Clock dependency: Client and server must agree within ~30 seconds. Significant clock drift causes authentication failures. (Solved by most implementations accepting ±1 window.)
  • Real-time phishing possible: Codes are valid long enough for a fake site to relay them to the real site. (Solved by hardware keys / FIDO2.)

Side-by-Side Comparison

Feature HOTP TOTP
RFC RFC 4226 (2005) RFC 6238 (2011)
Counter mechanism Integer counter Unix timestamp / period
Code validity Until next button press 30 seconds (default)
Clock sync required No Yes (within ~60 seconds)
Replay attack window Until counter advances 30 seconds
State management Counter must stay in sync Stateless (clock is the state)
Typical use Hardware tokens, YubiKey OTP mode Authenticator apps (Google Authenticator, Authy)
Adoption Legacy / hardware tokens Dominant in software 2FA

Which Should You Implement?

For software authenticator apps: TOTP. It's the universal standard  every authenticator app implements it, and users expect the 30-second refresh cycle. The time synchronisation requirement is trivially met by any internet-connected device.

For hardware tokens: HOTP. Hardware tokens with a button that generates on-demand are a natural fit for counter-based OTP. The most prominent example is YubiKey in OTP mode (though modern YubiKeys also support TOTP via the OATH application).

For new implementations: always start with TOTP unless you have a specific reason to use HOTP. The ecosystem, tooling, and user familiarity are overwhelmingly TOTP-oriented.

Test TOTP implementation with our free TOTP code generator and generate test secrets with our 2FA Secret Generator.

Frequently Asked Questions

Does Google Authenticator support HOTP?

Yes  Google Authenticator supports both TOTP and HOTP. You can add an HOTP account by using an otpauth URI with type "hotp" instead of "totp". In practice, most accounts use TOTP.

Is HOTP less secure than TOTP?

The underlying cryptography is identical. HOTP has a larger replay window (codes don't expire until used), which is a security disadvantage. However, for hardware tokens used in controlled environments, this is often acceptable. TOTP is generally preferred for software 2FA because of the time-based expiry.

What is STEAM Guard? Is it TOTP or HOTP?

Steam Guard Mobile Authenticator uses a variant of TOTP with a custom character set (26 letters rather than digits) and a 5-character code. It's based on TOTP but with non-standard parameters, which is why regular authenticator apps can't add Steam accounts in the normal way you need the Steam app or a specialised app that supports Steam's variant.

What does "period" mean in TOTP?

The period is the time step how long (in seconds) a code is valid before the next one generates. The standard is 30 seconds. Some services use 60 seconds for a larger input window. The period is included in the setup QR code so authenticator apps know which interval to use.

Shoyeb Akter

Written by

Security Tools Developer and creator of 2FA Fast — a privacy-first browser-based authenticator and security tools platform.