Robert Morris, Ken Thompson, and the Unix Password File: Hashing Secrets Instead of Storing Them
Unix password security evolved from storing reusable secrets toward storing salted one-way verifiers, establishing a pattern that remains fundamental to password databases even though the original DES-based scheme is long obsolete.
Password files exposed a basic problem with reusable secrets
Early time-sharing systems needed a way to authenticate many remote users, but storing each user’s actual password created a dangerous concentration of reusable secrets. Robert Morris and Ken Thompson’s 1979 case history describes how Unix password protection evolved through repeated attacks and countermeasures rather than appearing as a finished design from the start.[1]
The durable idea was simple: the system should be able to verify a password without retaining the original password in recoverable form.
Unix moved from plaintext passwords to one-way verification
Morris and Thompson describe an early design in which actual passwords had to be heavily protected, making every accidental disclosure catastrophic. The improved design stored the result of a one-way transformation instead. At login, the system transformed the user’s candidate password and compared the result with the stored verifier.[1]
This changed the failure mode. Reading the password file no longer revealed the passwords directly, although attackers could still perform offline guesses and compare their computed results with the stored values.
Verification without recovery became the architectural goal
The server did not need to decrypt a stored secret. It only needed a deterministic way to test whether the supplied password produced the same verifier as the original.
The Seventh Edition crypt routine deliberately modified DES
The Unix V7 crypt manual describes a password routine based on the U.S. Data Encryption Standard with deliberate variations intended to frustrate direct use of DES hardware for key searching.[2] The user’s password supplied the key material, and a constant value was repeatedly transformed.
This was computationally expensive by the standards of the period, turning each password guess into real work rather than a trivial comparison.
Password hashing is not ordinary data encryption
The goal is not to recover the original password later. A password verifier should make checking legitimate logins practical while making large numbers of offline guesses costly.
Salt prevented one precomputed guess from matching every account
The V7 crypt interface accepted a two-character salt that perturbed the DES computation in one of 4,096 ways.[2] Users with the same password could therefore end up with different stored verifier strings.
Salt does not need to be secret. Its value can be stored beside the hash. Its purpose is to force attackers to recompute guesses for different salt values and to prevent simple equality checks across many accounts.
The public password file was an intentional tradeoff
The V7 passwd file format explicitly noted that encrypted password values allowed the file to remain generally readable so ordinary programs could map user IDs to names.[3] That design improved system convenience while assuming the one-way scheme would resist feasible guessing attacks.
Offline guessing became the central weakness of the model
Once an attacker obtains a password verifier database, login rate limits no longer matter. The attacker can guess locally at hardware speed. Morris and Thompson were already concerned with dictionary attacks, password choice and the economics of guessing.[1]
This is why password storage algorithms must evolve with hardware. A construction that is expensive enough on one generation of computers can become dangerously cheap decades later.
Slow verification is a security feature when used carefully
For interactive authentication, legitimate users perform only a few checks. An attacker may attempt billions. Password hashing deliberately exploits that asymmetry by making each guess more expensive.
The original Unix construction became obsolete but the pattern survived
The DES-based Unix scheme is no longer considered adequate. Modern systems moved through shadow password files, stronger hash functions and purpose-built password key-derivation functions. A USENIX retrospective on bcrypt traces that later evolution while identifying Unix crypt as an important origin point for modern salted password verification.[4]
The lesson is historical rather than algorithmic: the original parameters should not be copied, but the architectural separation between a user’s secret and the stored verifier remains fundamental.
Modern guidance still requires salted, expensive password hashing
Current NIST digital-identity guidance says password verifiers should store passwords in a form resistant to offline attacks using salted password hashing with an appropriate cost factor.[5] Modern salts are far larger than Unix’s original 12-bit value, and contemporary password hashing schemes are designed to consume substantially more computation or memory.
The guidance reflects the same adversarial model Morris and Thompson confronted: assume the verifier database may eventually be stolen, then make each offline guess as expensive and non-reusable as practical.
Why the Unix password file belongs in security history
Morris and Thompson documented an engineering transition from protecting a file full of reusable secrets to storing one-way verifiers shaped by salts and computational cost.[1] The V7 manuals show how that design was exposed as a normal system interface rather than hidden as an academic experiment.[2][3]
Later schemes such as bcrypt and modern NIST guidance changed the cryptographic machinery, but retained the central idea: a system should authenticate a password without keeping the password itself in reusable form, and should assume attackers may someday perform offline guesses against the stored database.[4][5]
Works Cited
- 01Robert Morris and Ken Thompson — Password Security: A Case History (CACM, 1979) wolfram.schneider.org
- 02
- 03
- 04
- 05
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead