Visual RFC.
ALL RFCs / RFC 4226
Read the RFC ↗

RFC 4226 / START HERE

HOTP counter codes, before the details

HOTP means HMAC-Based One-Time Password. HMAC is a keyed message authentication code: a calculation that uses a secret key and input bytes.

A token and a server share a secret and keep event counters. Each request for a new token code advances the token counter. Both sides calculate a short decimal code from the secret and counter; the server compares its result before consuming the matched counter.

Start the guide See the 5 chapters ↓

The idea in one picture

  1. Token counter

  2. Short code

  3. Server check

A simplified picture of the idea; the chapters explain the actual mechanisms.

Why it exists

This December 2005 Informational publication defines an interoperable counter-based algorithm and important validation controls. It complements RFC6238’s time-based codes without a formal update relationship. It does not define a complete modern login system or encrypt traffic.

A familiar example

Imagine pressing a small token button while signing in to a fictional service. A skipped press can move the token ahead, so the server checks a small forward window. Another factor, protected secrets, a secure channel and limits on attempts still matter; possession of a code alone does not establish a complete login.

Helpful background

You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.

Time-based one-time passwordsRFC 6238 · beginner overview ↗HKDFRFC 5869 · beginner overview ↗

What you’ll learn next

Begin with chapter one, or choose a topic.

  1. Keep token and server counters distinctA token makes a new code after a button press. The server calculates its own expected value using its copy of the secret and counter.
  2. Encode the counter before HMACHOTP uses HMAC-SHA-1 over an eight-byte counter. Hexadecimal text is a readable notation for those bytes.
  3. Select four bytes and reduce to digitsDynamic truncation uses the low four bits of the last HMAC byte to choose four consecutive bytes.
  4. Resynchronize within a bounded windowUnused button presses can put a token ahead of the server. The server checks a small forward range and consumes a match.
  5. Limit guessing and protect the whole protocolA short code needs a secure channel, protected shared secrets, another factor and server-side attempt limits.
Start with chapter one →

This introduction explains RFC 4226 (2005). Read the original RFC ↗