Category: Multi-Factor Methods
HMAC-Based One-Time Password
Also known as: HOTP, HMAC-based one-time password
Simply put
HOTP is a method for generating single-use passcodes used as an authentication factor. Each code is produced from a secret key shared between the user's device and the server, combined with a counter that advances each time a new code is generated. Because the code changes with every use rather than by time, it is described as event-based.
Formal definition
HOTP, defined in RFC 4226, is an event-based one-time password algorithm that derives OTP values from an HMAC computed over a shared secret key and an incrementing event counter (the moving factor). The HMAC output is truncated and reduced to a human-readable numeric code, typically of a configurable digit length. As a possession-based authentication factor, HOTP relies on the server and token remaining synchronized on the counter value; because the counter advances only on generation rather than with elapsed time, HOTP differs from the time-based variant (TOTP), which uses a time step as its moving factor. HOTP addresses the credential-verification (authentication) step and does not by itself define authorization or provisioning behavior; its security depends on protecting the shared secret and managing counter synchronization, and specific digit counts and hash choices depend on deployment configuration.
Why it matters
HOTP, standardized in RFC 4226, was one of the foundational open algorithms that made interoperable one-time password authentication possible across vendors and token types. Before such standards, OTP hardware and software were often tied to proprietary systems; HOTP defined a publicly specified way to derive single-use codes from a shared secret and a counter, enabling possession-based factors that any conforming server and token could implement. For IAM teams, this matters because it underpins a broad class of second-factor deployments and directly informs the design of its more widely used time-based sibling, TOTP.
Who it's relevant to
IAM Engineers and Architects
Those designing multi-factor authentication need to understand HOTP as a possession-based factor and how its event-based counter model differs from TOTP. Design decisions such as resynchronization windows, secret provisioning, and digit length affect both usability and security, and the choice between HOTP, TOTP, and phishing-resistant factors like FIDO2/WebAuthn depends on the deployment's threat model.
System Administrators
Operators who provision and support OTP tokens must manage the shared secrets and, critically, handle counter drift between token and server. Because a HOTP code stays valid until consumed and the counter only advances on generation, help-desk and resynchronization procedures are a routine operational consideration.
Security Architects and Compliance Officers
When evaluating whether an authentication control meets a given standard or policy, it helps to know that HOTP is an open, RFC 4226-defined algorithm and to understand its limitations, specifically that it verifies a possession factor but does not by itself address authorization, provisioning, or phishing resistance. Its security depends on protecting the shared secret.
Vendors and Integrators Building OTP Support
Because HOTP is publicly specified, developers implementing OTP validation can build interoperable server and token support. Attention to truncation, configurable digit length, and counter-synchronization logic is necessary for conformance and for reliable interoperation with tokens from other sources.
Inside HOTP
Shared secret key
A symmetric secret provisioned to both the authenticator (token or app) and the validating server. HOTP derives each one-time password from this key, so its confidentiality is fundamental to the scheme's security.
Counter value
A moving factor that increments with each generated password. Because the counter changes rather than the clock, HOTP is event-based rather than time-based; the client counter increments on generation while the server counter increments upon successful validation.
HMAC computation
HOTP applies a keyed-hash message authentication code over the counter using the shared secret to produce a message digest. The security of the resulting value depends on the secrecy of the key rather than the secrecy of the algorithm.
Truncation and modulo step
The HMAC output is reduced through a dynamic truncation function and a modulo operation to yield a short numeric code, typically 6 to 8 digits depending on configuration, that a user can enter manually.
Look-ahead / resynchronization window
Because client and server counters can drift out of alignment (for example when a user generates codes without submitting them), validators typically accept a configurable range of upcoming counter values and resynchronize on a match.
Possession factor role
In an authentication flow, an HOTP value serves as evidence of a possession factor (control of the provisioned authenticator). It contributes to authentication and does not by itself perform authorization.
Common questions
Answers to the questions practitioners most commonly ask about HOTP.
Is HOTP the same thing as TOTP?
No. Both are one-time password algorithms from the OATH family, but they differ in what drives the moving factor. HOTP is event-based, deriving each OTP from an incrementing counter that advances each time a code is generated. TOTP is time-based, deriving the OTP from the current time within fixed intervals. TOTP is commonly described as a variant built on the HOTP construction, with a timestep replacing the counter. They are related but not interchangeable, and a validator must be configured for the correct mode.
Does HOTP provide authentication by itself, or is it just one part of the process?
HOTP is a mechanism for verifying possession of a shared secret, so it typically serves as one authentication factor rather than a complete authentication solution. It demonstrates a possession factor (control of the seed, usually held by a token or app), but it does not by itself establish identity or determine what a principal may do. In most deployments it is combined with another factor, such as a password, to form MFA, and it remains distinct from authorization, which is a separate step handled after authentication succeeds.
How should the validator handle counter drift between the client and server?
Because HOTP is event-based, the client counter can advance beyond the server counter if a user generates codes that are never submitted. To tolerate this, validators typically implement a look-ahead window, accepting a code that matches any counter value within a bounded range past the server's current value, then resynchronizing the stored counter on a successful match. The window size is a configuration tradeoff: a larger window improves usability but expands the set of simultaneously valid codes. Behavior varies by implementation and configured window.
How is the shared secret provisioned and stored?
HOTP relies on a symmetric seed shared between the token or authenticator and the validating server. Provisioning approaches vary by deployment, and secrets are commonly distributed via provisioning URIs, QR codes, or hardware token import files, depending on the vendor and form factor. Because the secret is symmetric and its compromise undermines the factor, it should be protected at rest on the server side according to your key management practices. Specific storage and encryption mechanisms depend on the implementation and are outside the scope of the HOTP algorithm itself.
What length and format should generated HOTP codes use?
HOTP applies a truncation step to an HMAC output to produce a numeric code, and the number of digits is a configurable parameter, with 6-digit codes being common in many deployments. Shorter codes are easier for users to enter but reduce the space an attacker must guess, so the digit count interacts with rate limiting and lockout controls. Choose a length and pair it with brute-force protections appropriate to your risk tolerance; exact defaults depend on the implementation.
What happens if a generated code is never submitted, and how do you prevent lockout?
When a user generates codes that are not submitted, the client counter advances while the server counter does not, which can eventually push the client outside the validator's look-ahead window and cause failures. Mitigations depend on configuration and typically include a reasonable look-ahead window plus a resynchronization procedure, in which the server accepts two consecutive codes to realign counters. The trade-offs between window size, resynchronization flows, and brute-force resistance are deployment-specific.
Common misconceptions
HOTP and TOTP are interchangeable.
They share the same HMAC-based construction, but HOTP is event-based, using an incrementing counter as its moving factor, whereas TOTP substitutes a time-based value. This difference affects synchronization behavior, replay window handling, and how codes expire, so they are not drop-in equivalents.
Because HOTP produces a code tied to a secret, the one-time password is encrypted or otherwise confidential in transit.
An HOTP value is a truncated output derived from an HMAC; it is not an encrypted payload. It should still be transmitted and validated over a protected channel, and its security rests on keeping the shared secret confidential rather than on any encryption of the code itself.
Delivering HOTP codes means multi-factor authentication is in place.
HOTP typically supplies one possession factor. Whether an overall flow is MFA depends on combining it with a distinct factor such as knowledge or inherence; using HOTP alone, or alongside another possession-based mechanism, does not necessarily satisfy MFA requirements.
Best practices
Provision and store shared secrets securely at both the authenticator and the validating server, protecting them at rest and limiting exposure during enrollment, since compromise of the secret undermines the entire scheme.
Configure a bounded look-ahead window to tolerate counter drift, keeping it wide enough for legitimate resynchronization but narrow enough to limit an attacker's guessing surface, and resynchronize the server counter on successful validation.
Enforce that each counter value is accepted only once and advance the server counter past validated values to prevent reuse or replay of previously generated codes.
Transmit and validate HOTP codes over a protected transport channel, and do not treat the code as confidential or encrypted by virtue of its derivation.
Combine HOTP with a factor from a different category (knowledge or inherence) when the goal is genuine multi-factor authentication, rather than relying on it in isolation.
Apply rate limiting and lockout controls on validation attempts and consider step-up authentication for higher-risk operations, since short numeric codes are susceptible to online guessing without such protections.
