HOTP and TOTP are the two algorithms that compute a one-time passcode, each from a secret shared with the device. A passcode your server generates and sends is computed by neither of them.
What does each acronym name?
Two of the three name algorithms.
- OTP, one-time passcode: any passcode valid once, then discarded. It says nothing about where the code came from. What does OTP mean covers the category.
- HOTP: RFC 4226 computes the code from a shared secret and a counter. "The HOTP algorithm is based on an increasing counter value and a static symmetric key known only to the token and the validation service."
- TOTP: RFC 6238 supplies that counter from the clock. "Basically, we define TOTP as TOTP = HOTP(K, T), where T is an integer and represents the number of time steps between the initial counter time T0 and the current Unix time."
TOTP is HOTP with the clock as its counter. Both need a secret shared between the device and the verifier. Neither sends anything over the network when a code is produced.
What is the difference between HOTP and TOTP?
What makes the code change, and therefore when it stops working.
A HOTP code changes when the counter advances, which happens when a code is generated. It does not expire on a clock. A code produced and never submitted stays valid until something moves the counter, so RFC 4226 requires a way back: "There MUST be user-friendly mechanisms available to resynchronize the counter."
A TOTP code changes as the time step advances, whether anyone used it or not. RFC 6238 sets the step: "X represents the time step in seconds (default value X = 30 seconds)", and recommends keeping it there "as a balance between security and usability". It also bounds how late a code may arrive: "We RECOMMEND that at most one time step is allowed as the network delay."
NIST SP 800-63B section 3.1.4.1 puts the split in one sentence:
Single-factor OTP authenticators and verifiers contain two persistent values: 1) a symmetric key that persists for the authenticator's lifetime and 2) a nonce that is either changed each time the authenticator is used or is based on a real-time clock.
The two halves of that "either" are HOTP and TOTP. The same section caps the clock-based case: "If the nonce used to generate the authenticator output is based on a real-time clock, the nonce SHALL be changed at least once every two minutes."
Is the code my app texts a TOTP?
No. A passcode you send is generated by the server and delivered.
There is no shared secret on the person's device, no counter and no time step. The code is valid because the server recorded issuing it. NIST SP 800-63B governs it under out-of-band devices, section 3.1.3, with the authenticator at 3.1.3.1 and the verifier's obligations at 3.1.3.2, rather than as the single-factor OTP of 3.1.4.
Bird's Verify generates each passcode from a cryptographic random source, stores it as an HMAC hash, and compares submissions in constant time. The settings that govern it are length, validity and attempt count: how long should an OTP be valid, and how many digits covers all three.
Which one should I use?
Choose by what you can require of the person.
- A delivered passcode needs only a working number or address, which suits onboarding and account recovery. It depends on a delivery channel, so it can be slow or intercepted.
- TOTP in an authenticator app needs prior enrolment and a device the person keeps. It sends nothing at the moment of use, which suits an established account.
- HOTP suits a device whose clock you cannot rely on, such as a hardware token.
Many products use two: a delivered passcode to establish the account, an app code for repeat sign-ins.
How do they fail differently?
Each has one characteristic failure, and the remedies are unrelated.
| Kind | Characteristic failure | What resolves it |
|---|---|---|
| HOTP | Counter drift, from codes generated and never submitted | A resynchronisation path, required by RFC 4226 |
| TOTP | Clock drift on the device, or a code entered a step too late | A tolerance window, bounded at one step by RFC 6238 |
| Delivered passcode | The message arrives late or not at all | Measuring arrival, then a second channel |
The delivered case fails invisibly from the server: the code was correct and never reached anyone. How do I measure how long my OTPs take to arrive covers making it visible.
All three share the risk of brute force, and all three specifications answer it by limiting guesses. RFC 4226 recommends a throttling parameter "as low as possible, while still ensuring that usability is not significantly impacted". NIST caps consecutive failures in section 3.2.2.
In short
OTP is the category, HOTP and TOTP are algorithms.
A one-time passcode is any passcode good for a single use. HOTP and TOTP each compute one from a secret shared with the device.
HOTP advances a counter, TOTP reads the clock.
RFC 4226 changes the code when a code is generated. RFC 6238 changes it every time step, by default every 30 seconds.
A passcode you send is neither.
The server generates it at random and delivers it. There is no shared secret on the device, so NIST governs it as an out-of-band authenticator.
A HOTP token drifts by counter, a TOTP token by clock.
RFC 4226 requires a resynchronisation path. RFC 6238 bounds the verifier's tolerance at one time step.
Six digits is the floor in both specifications.
RFC 4226 requires at least six digits. NIST allows truncation to six, with rate limiting as the control that makes six safe.