Summary

  • RFC 1938 resisted passive password replay with a descending one-way hash chain: the server accepted a response only if hashing it produced the stored verifier, then replaced that verifier with the accepted response.
  • Success therefore changed the next truth condition. Atomic update, simultaneous-session defence, sequence exhaustion and safe reinitialisation were part of authentication itself.
  • The design kept the passphrase off the network, but it did not encrypt the session or defeat active attacks; later HOTP and TOTP defined different moving-state systems.

A fact that expired when proved

Imagine two terminals submitting the same valid password at almost the same instant. In an ordinary reusable-password system, both comparisons may return true. In the system specified by RFC 1938, only one should cross the boundary. Once the first succeeds, the server’s record changes. The second is no longer an equivalent proof, even though no character in it has changed.

That is the document’s durable idea. The RFC Editor record dates the Proposed Standard to May 1996 and now marks it obsolete, pointing to RFC 2289. But the historical interest lies less in the status label than in the state machine hidden behind the phrase “one-time password.”

The user starts with a secret passphrase and a public seed. A generator mixes them and repeatedly applies a one-way hash. At a chain depth N, the first presented value sits at the far end, H^N(S). The next login walks backward to H^(N-1)(S). The server need not retain the passphrase. It keeps the last accepted 64-bit verifier and the sequence position.

For a submitted value x, the server computes H(x). If the result equals the stored verifier, x is valid. Then the server stores x. The crucial verb is not compare but replace. The verifier that made x acceptable disappears, and x becomes the reference against which the next response is tested. A captured x offered later will hash to the old verifier, not to the new one. Replay fails because successful authentication has moved the shared boundary.

The idea grew from the Bellcore S/KEY system documented in RFC 1760. Its target was practical and narrow: people were logging in across networks where reusable passwords could be observed. A one-time chain reduced the value of passively captured traffic without requiring the user’s secret passphrase to traverse that traffic.

The six words were an interface, not six secrets

RFC 1938’s challenge made the moving state visible: algorithm, sequence and seed, in a form such as otp-md5 487 dog2. MD5 support was mandatory, SHA recommended and MD4 permitted. Both ends had to agree, and the weakest accepted algorithm could set the security floor.

The generated value was 64 bits, awkward to type accurately. The standard therefore mapped it to six words from a 2,048-entry dictionary. Each word selected 11 bits, carrying 66 bits in total. The two extra bits acted as a checksum for entry and decoding errors. They helped distinguish a mistyped phrase from a valid encoding. They did not authenticate the user a second time, and the words carried no protective semantics of their own.

This distinction matters because representations acquire folklore. A memorable phrase can look like a human secret, while in this protocol it was an encoding of machine-produced state. Servers had to accept the standard word form and hexadecimal, and were encouraged to accept alternate-dictionary input. Case folding, dictionary choice and decoding therefore sat on the interoperability path. Cosmetic normalisation could decide whether the same 64 bits reached the verifier.

One successful transition, even under pressure

The state model created a race. RFC 1938 considered an attacker who heard most of a six-word response, guessed the rest and tried to arrive before the legitimate user. A conforming server had to protect against this. Blocking simultaneous authentication sessions for one account was suggested, together with a timeout so that the defence did not become a permanent denial of service.

The risk was broader than that example. If two server processes read the same old verifier, independently accept the same response and only later write the new value, one consumable proof has produced two successes. Cryptographic comparison can be perfect while transactional behaviour is wrong. The account record needs an atomic compare-and-advance, or an equivalent serialisation rule, because concurrency determines the truth the protocol is meant to create.

The chain also ends. A sequence number is not decoration: it measures remaining usable responses. Reinitialisation needs a new seed or passphrase, because reusing both regenerates a chain whose values may already have crossed an observed network. Transmitting the secret passphrase in clear text to repair the state defeats the central design.

There is an especially instructive edge. A recommended reset flow could ask for an old OTP before installing a fresh chain. At sequence count one, a user might spend the last response logging in and have none left to authorise reinitialisation. Availability therefore depended on acting before cryptographic inventory reached zero. The “password system” included lifecycle policy.

Obsolescence did not erase the boundary

RFC 2289’s current record marks the successor as a 1998 Proposed Standard. The replacement specification preserved the descending-chain model while tightening details, adding test vectors and sharpening operational advice. Its recommendation to use IPsec against threats such as TCP connection hijacking makes an important limit explicit: an OTP can improve the login proof without protecting the connection that follows it.

Later standards placed moving state elsewhere. HOTP calculates a value from a shared secret and an increasing counter; a verifier may search a look-ahead window to resynchronise and advances its counter after success. TOTP uses a time step as HOTP’s moving factor and requires that a successfully validated value not be accepted again within that step. These are useful comparisons, not evidence that they descended from S/KEY. Their secrets, direction of movement and resynchronisation problems differ.

Across all three, however, “does the number match?” is too weak a model. A validator must know which state is current, which nearby states it may tolerate, what success consumes, and how replicas agree. Authentication is partly cryptography and partly the governance of change.

Nor should a valid login be promoted into a larger claim. RFC 1938 did not provide privacy or general protection against active attack and social engineering. Acceptance proves that a response fits the configured account state. It does not by itself establish authorisation for a command, confidentiality of the ensuing session, durable access, successful execution, or the civil identity of the human at the keyboard.

The label and the machinery

Heng Lu’s argument for running-code primacy helps expose why this RFC remains useful. The specification names a transition, but implementations decide whether two processes can both claim it, whether state survives failure, and whether reset closes or reopens a replay path. Operational evidence tests the promise.

The discipline of a minimum initial specification is visible too. The shared core can be compact: define the chain, challenge, representations, acceptance test and state advance. Local software may vary, but not in a way that changes one consumable answer into two accepted sessions.

Finally, the distinction among reality layers prevents the phrase “one-time” from doing more work than the system. One-time is a symbolic claim. Its operational reality is a stored verifier, an atomic mutation, a race policy, a finite sequence and a controlled reset. If any of those layers drift, a password can be correct in computation and wrong in history—or accepted twice despite being named one-time.

RFC 1938’s deepest lesson is therefore not that secrets should be longer or codes should change. It is that a proof can alter the world in which the next proof is judged. Once authentication has that property, success is no longer a read. It is a write that must be owned, ordered and remembered.

Sources

  1. RFC Editor — RFC 1938 current record
  2. RFC 1938 — A One-Time Password System
  3. RFC 1760 — The S/KEY One-Time Password System
  4. RFC Editor — RFC 2289 current record
  5. RFC 2289 — A One-Time Password System
  6. RFC 4226 — HOTP: An HMAC-Based One-Time Password Algorithm
  7. RFC 6238 — TOTP: Time-Based One-Time Password Algorithm
  8. Heng Lu — Running-Code Primacy
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  10. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile