An authenticator app can produce a code without receiving a message. A texted passcode arrives through a delivery channel instead, so the setup and failure handling differ.
What does each term mean?
OTP describes a code accepted once. HOTP and TOTP describe algorithms for generating that code.
| Term | What supplies the code | What the user needs |
|---|---|---|
| OTP | The general category, independent of the generation method | Depends on the chosen method |
| HOTP | A shared secret and an advancing counter | An enrolled token or application |
| TOTP | A shared secret and the current time interval | An enrolled authenticator with a usable clock |
RFC 4226 defines HOTP's shared secret and counter. RFC 6238 uses time in place of that counter for TOTP.
The authenticator and verifier need the same secret to calculate matching codes. Protect that secret during enrollment and storage, since possessing it enables code generation.
How does HOTP change its code?
The token advances a counter when it generates a code. The verifier advances its corresponding state after accepting the expected code.
A HOTP code does not expire solely because time passes. Generating codes without submitting them can move the token ahead of the verifier.
Provide the counter resynchronization required by HOTP's specification. Bound the search for later counter values, because accepting more candidates increases the opportunity to guess.
Keep unsuccessful authentication attempts limited during that process. Resynchronization must not become a route to unlimited guesses.
How does TOTP change its code?
TOTP generates a code from the shared secret and the current time interval, even when nobody requests a new code.
RFC 6238 recommends a 30-second time step. The displayed code changes as the clock crosses into the next interval.
A code entered near an interval's end can reach the verifier during the following interval. Allow a bounded delay so that ordinary entry timing does not cause unnecessary failures.
The RFC recommends at most one step for network delay. That recommendation concerns transmission delay; it is not a universal limit on all clock resynchronization.
Keep the device and server clocks aligned. A broad acceptance window accommodates more drift. It also accepts more candidate codes.
Reject an already accepted code even inside its time interval. The clock changing later does not provide single-use enforcement by itself.
Is a passcode sent by Bird a TOTP?
No. Bird Verify generates a random passcode and delivers it through the selected channel.
The recipient does not enroll a shared authenticator secret to receive that code. Its validity follows the verification's expiry and attempt policy, rather than an authenticator's counter or clock interval.
Choose the code length, expiry and attempt limit for the verification flow. Measure the delivery and completion intervals when recipients report delays.
HOTP and TOTP generate codes locally after enrollment, so they do not wait for a message at sign-in. Their recovery instead needs to account for a lost authenticator or shared secret.
Which method should I choose?
- Use a delivered passcode when the flow needs to verify access to a reachable number or address.
- Use TOTP when users can enroll and retain an authenticator with a reliable clock.
- Use HOTP when the token cannot rely on time and you can maintain counter synchronization.
- For every method, limit guesses, enforce single use and define account recovery before launch.
In short
OTP is the category.
HOTP and TOTP are ways to generate one-time codes. A server can also generate and deliver a random passcode.
HOTP follows a counter.
Generating unused codes can move the device ahead of the verifier. Provide a bounded way to resynchronize them.
TOTP follows the clock.
The recommended time step is 30 seconds. Account for entry delay without making the acceptance window unnecessarily broad.
Choose the enrollment and recovery model.
Authenticator codes need a previously shared secret. Delivered codes need a working delivery channel.