The Shared Secret

13.0 What this chapter gives you#

1. You will be able to explain what a password is, a secret two parties both hold, and why that one decision causes every problem that follows.
2. You will be able to date the password: the machine, the year, the man who put it there, and the student who stole the file eight months later.
3. You will be able to describe the four changes Morris and Thompson made in 1979 and name the attack each one answers.
4. You will be able to compute the entropy of a password recipe in bits by hand, and state what that number does not tell you.
5. You will be able to explain why guessing entropy is the wrong measure of an attacker’s work, and what replaced it.
6. You will be able to describe the shape of human password choice and quote fitted numbers from a corpus of 32,603,388 passwords.
7. You will be able to show with arithmetic why reuse, not weakness, is what actually loses accounts.
8. You will be able to size a credential stuffing campaign: corpus, overlap, hit rate, time and bandwidth.
9. You will be able to state what a password verifier must do under NIST SP 800-63B Revision 4 of July 2025.
10. You will be able to say where the password still wins, and what it would take to retire it.

The password is the oldest security control still in daily use in computing, and close to the only one that has never been replaced. It works today almost exactly as it worked in 1962: you think of a word, you tell the word to a computer, the computer remembers something about the word, and the next time you appear you say the word again. That is the entire mechanism. It was designed to stop one MIT researcher reading another MIT researcher’s files on a machine shared by a few dozen people who knew each other by name, and it now stands between organized crime and several billion bank accounts.

This chapter is about that gap, in roughly equal parts history, arithmetic and honesty. The history matters because almost every strange thing about passwords is a fossil, a decision made for a good reason on a machine with 32 thousand words of memory that nobody has been able to undo since. The arithmetic matters because passwords are the one part of identity where you can actually calculate the risk, and the calculations contradict most of what people are told. The honesty matters because standard password advice has been substantially wrong for about thirty years, and the corrections reached the standards documents only recently.

The chapter before this one set out the three classical factors of authentication, the things you know, have and are. The password is the whole of the first factor, and it carries a burden the other two do not, because a secret you know is a secret you must give away every time you use it. The chapter after this one deals with the other half of the problem, how a service checks your password without being able to learn it, and this chapter deliberately leaves that alone. Here we are concerned with the secret itself: where it came from, how much of it there is, how people choose it, and what an attacker does with a billion of them.

One warning before we start. Breach numbers are the most inflated figures in the industry, because headlines routinely count rows in a file rather than people. Where this chapter gives a number, it names the corpus, the date and who counted it.

The plain version#

A club, a doorman, and a spoken phrase#

Imagine a private club with one door and one doorman. The club has members, and the doorman cannot possibly know them all by face, because there are twelve thousand of them and he works nights.

So the club uses a spoken phrase. When you join, you choose a phrase and tell it to the doorman, who writes it in a notebook next to your name. When you come to the door, you give your name and say your phrase. The doorman looks up your name in the notebook, compares what you said with what is written, and lets you in if the two match.

This is a password, exactly. Everything real systems do is a refinement of this, and every weakness real systems have is already present in this picture, if you look hard enough.

Notice what makes the scheme attractive. It costs nothing and needs no equipment: no cards to print, no machines to buy. It works over any channel that carries words, so the doorman could do it by telephone. A forgotten phrase is replaced in a minute, and a departing member costs one crossed-out line. Nothing about it is clever, and that is its strength; the word “password” existed long before computers did.

Now notice the thing that will eventually ruin it. The doorman has to know the phrase. He cannot check what you say against something he does not hold. So the secret is not really yours; it is jointly held, by you and by a notebook in a hut by the door. That is why we call it a shared secret: a piece of information that two parties both hold, and that either of them can leak.

The notebook is the whole problem#

Suppose the notebook is stolen.

Not broken into, not decoded. Simply picked up and carried away one Friday night. The thief now has twelve thousand names and twelve thousand phrases. Every member of the club is compromised at once, and none of them did anything wrong. They chose good phrases, they never said them aloud in the street, they never wrote them down. It made no difference, because the club wrote them down, and it had to.

This is not hypothetical. It is the first thing that ever happened: in the spring of 1962, at MIT, a student carried away the notebook because he wanted more time on the computer.

There is a fix, and it is a beautiful one. The doorman does not need to know your phrase; he only needs to recognize it. Imagine that instead of writing the phrase down, he puts it through a machine that turns any phrase into a five-digit number in a way that cannot be run backwards. Your phrase becomes 48211, and 48211 is what goes in the notebook. When you come to the door, he puts what you said through the same machine and checks that he gets 48211 again.

Now stealing the notebook gets the thief a list of numbers, not phrases. He can only guess phrases, run each through the machine, and see whether the results match. That is a different kind of work: not copying, but searching. The whole of chapter 14 is about making that search as slow and as useless as possible, so we leave it there, noting only that this idea, called a one-way function, arrived at the end of the 1960s and is the single most important improvement the password has ever received.

It does not solve the problem. It changes it. The thief with the notebook of numbers can still guess, and people are extremely guessable.

People do not choose randomly#

Ask twelve thousand people to each invent a phrase, and you will not get twelve thousand different phrases. You will get a few hundred phrases repeated over and over, and a long, thin tail of unusual ones.

We know this exactly, because it has been measured on real people many times, and the measurements agree. Here is the clearest one. In December 2009 a company called RockYou, which made small applications for social networking sites, was broken into, and the passwords of 32,603,388 of its users were published. They were stored as plain text, so no guessing was needed to read them. Researchers have been studying that list ever since, because it is the largest fully readable record of how ordinary people choose secrets.

The single most popular password in that list was 123456. It was chosen by 290,731 people. That is 0.89 per cent of everybody, which means that a stranger who knows nothing at all about you, and who is allowed exactly one guess at each account, gets into roughly one account in every hundred and twelve.

Here are the top ten, as published in the analysis of the breach by the security firm Imperva in early 2010.

Add those ten numbers together and you get 677,819 people, which is 2.08 per cent of the whole membership. Ten guesses per account, the same ten guesses for everybody, no cleverness, no research, no personal information: two accounts in every hundred fall open.

That is the plain fact that the rest of this chapter builds on. The security of a password system is not the security of the best password in it. It is the security of the worst few per cent, because that is where the attacker is going to spend his time.

The same phrase at every door in town#

Now the part that actually costs people their money.

Our club member also belongs to a gym, a library, a chemist’s loyalty scheme and an airline. Each has a door, a doorman and a notebook. Remembering five phrases is a genuine burden, so she uses one everywhere, or one with a small change at the end for each place.

The gym’s notebook is stolen. The gym is a small business, its notebook was not well protected, and nobody notices for a year. The thief now holds her name and her phrase, and he does not care about the gym. He walks to the airline, the chemist and the bank, and tries the same pair at each door.

This is the attack that matters, and it deserves its own name. Credential stuffing is taking name-and-phrase pairs stolen from one place and trying them, in bulk and by machine, at other places. Nothing is guessed and nothing is cracked. The thief already has the right answer; he is finding out how many other doors it opens.

Consider what this does to advice about strong passwords. Suppose our member’s phrase is not 123456 but one no attacker would find in a thousand years of searching. It makes no difference at all, because the gym gave it away. Strength protects against guessing and does nothing against copying. A password used in two places is only as safe as the weaker place, and you cannot tell which one that is.

That is why the single most useful thing an ordinary person can do about passwords is not to make them longer. It is to make them all different, which in practice means keeping them somewhere other than in your head, because nobody can memorize eighty distinct phrases.

The worked example we will carry through the chapter#

Let us set up one example now and follow it to the end of the chapter, getting more precise each time.

Meera lives in Pune and has an account at a grocery delivery service with eight million registered users. Her password there is Pihu@2019, which is her daughter’s name, the symbol the site demanded, and the year she opened the account. By every strength meter she has ever seen, this is a good password: nine characters, upper case, lower case, a symbol and digits. It is not in any list of common passwords.

Meera uses the same password at four other sites, one of which is a small online bookshop that was broken into in 2023 and did not notice.

In the plain telling, the story ends like this. The thief has Meera’s email address and Pihu@2019 from the bookshop. He tries them at the grocery service, along with three and a half million other pairs from the same collection, and about a quarter of a million of them work. Meera’s is one. Her strength meter was measuring how hard her password would be to guess, and nobody guessed it. In the technical half we do this arithmetic properly, with real corpus sizes, a measured hit rate from a published study, and the time and bandwidth the campaign takes.

Where the plain version stops being true#

There is no doorman, and there is no queue#

The club analogy puts one attacker at one door, saying one phrase at a time, in front of a man who can see him. Almost nothing about a real attack looks like that.

A real attacker is usually not at the door at all. He is somewhere else, with a copy of the notebook, on his own hardware, trying billions of phrases per second in private, with nobody to notice and nothing to slow him except the mathematics of the one-way function. This is called an offline attack, and it is why storage takes a whole chapter to itself.

When he is at the door, he is not in a queue. He is spread across thousands of network addresses, each making few requests, so no single address looks unusual. He is often not trying many phrases against one name either; he is trying one phrase against many names, which defeats the obvious defence of locking an account after five failures. That variation is called password spraying: one common password tried against every account in an organization, slowly enough that no account reaches its lockout limit.

The honest version: the doorman analogy describes the least important attack. Guessing at the front door is the case defenders control best and attackers rely on least. The dangerous cases are the ones where the attacker has already obtained a copy of something.

The doorman does not keep your phrase, and that changes what a leak is#

In the plain version the notebook holds phrases. In any competently built system since about 1970 it holds one-way transformed values, so a stolen database is not immediately a list of passwords; it is a list of puzzles.

This distinction is the difference between a bad night and a catastrophe, and it is worth being precise about, because news reports are not. When a service says passwords were exposed, it can mean plain text now public, reversible encryption with the key taken too, a fast one-way function that will give up most of the list within days, or a slow salted one that will give up only the weakest few per cent. Chapter 14 takes those four cases apart and shows what each layer defends against.

For this chapter the point is narrower. Whatever the storage, the weakest passwords fall out first and fastest. Storage decides how much of the list an attacker eventually reads; human choice decides which part he reads first, and how cheaply. Those are independent problems, and a service can get one right and the other wrong.

“Strong” is not a property a password has by itself#

The plain version implies that some phrases are strong and others are weak, as though strength were a property of the word, like its length.

It is not. Strength is a property of the relationship between your choice and the attacker’s search order. A password is weak precisely to the degree that an attacker will try it early. That is all weakness means.

This has consequences that sound wrong until you follow them through. The password P@ssw0rd1 contains upper case, lower case, a digit and a symbol, and satisfies almost every composition rule ever written; it is also in every attack list in existence, so it is worth nothing. A password of six random lower-case letters satisfies almost no composition rule and is far stronger, because nobody can predict which six. The character classes were never the point. Unpredictability was the point, and character-class rules measure unpredictability so badly that the standards bodies have now forbidden them, which we come to at the end of this chapter.

The honest version: there is no such thing as a strong password in isolation. There is only a password that is improbable under the distribution the attacker is sampling from, and that improbability is destroyed the moment the password appears in a published corpus, however improbable it looked when you chose it.

Your password does not have an entropy#

You will read that a certain password “has 60 bits of entropy”. This is a category error, and it is the most common one in the subject.

Entropy is a property of a random process, not of one of its outcomes. A coin flipped ten times produces ten bits of entropy; the particular result you got does not have ten bits, it is just a sequence. In the same way, the recipe “pick eight characters at random from the 62 letters and digits” produces 47.6 bits. The particular password that recipe gave you, say kR7pQ2xm, has no entropy at all once it exists, and if you had chosen those same eight characters yourself because they looked random, the number would be meaningless, because human choices cluster heavily.

So “this password has 60 bits of entropy” is only meaningful as shorthand for “this password was generated by a process with 60 bits of entropy”. If a human chose it, the sentence is not shorthand for anything. Strength meters say it anyway, because they must display something; what they are really doing is estimating how early an attack list would reach your password. Some do this quite well. None can do it correctly, because none of them knows which attack list.

Passwords are not obviously the worst option#

It is easy to finish a chapter like this believing the password is simply a mistake that should have been fixed decades ago. That is not quite right, and a book that left you believing it would have taught you a confident misunderstanding.

The password has properties nothing else has. It costs nothing to issue and nothing to replace. It works on hardware nobody has bought and over channels nobody has provisioned. It survives the loss of every device you own. It can be shared deliberately, which is sometimes exactly what a family or a small business needs. It requires no manufacturer, no chip supply chain, and no company that might go out of business. It is the only authenticator a person with nothing can use, and that is not a small property in a country where many first-time internet users arrive on a borrowed handset.

Every replacement so far has been better on security and worse on at least one of those axes. That is why the password has survived sixty-five years of people announcing its death, and why the honest engineering position, as of August 2026, is not “abolish passwords” but “stop relying on the password alone, and stop making the user carry a burden the system should carry”.

The technical version#

1961: CTSS, and the first password#

The Compatible Time-Sharing System, CTSS, was built at the MIT Computation Center under Fernando Corbato and first demonstrated in November 1961 on a modified IBM 709. It moved to an IBM 7090 in 1962 and later to 7094 machines. Its purpose was to let several people use one computer at once, each at a terminal, instead of submitting decks of punched cards and waiting hours for a result.

Time-sharing created a problem batch processing did not have. Several people were logged in simultaneously, each with a private set of files on shared storage, and the machine had to tell them apart. Corbato’s account of the reasoning is as plain as the solution:

“The key problem was that we were setting up multiple terminals which were to be used by multiple persons but with each person having his own private set of files. Putting a password on for each individual user as a lock seemed like a very straightforward solution.”

That quotation comes from an interview Corbato gave to the reporter Robert McMillan, published in January 2012, and it is worth reading twice. The password was not designed as a defence against an adversary. It was designed as a partition, a way of keeping colleagues’ files apart on a machine where everyone knew everyone. There was no threat model. There did not need to be one.

CTSS is widely credited as the first computer system with password login, and the credit is probably right, but it should be stated carefully. What is documented is that CTSS was demonstrated in November 1961, that its login procedure used a password, and that a complete password file existed and could be printed by the spring of 1962. The exact month in which the first password was set is not recorded in any source this chapter could find, and Corbato himself, in that 2012 interview, was reluctant to claim the invention. [UNVERIFIED: the precise date on which password login was first enabled on CTSS]

Hold the arithmetic of the era in mind. CTSS supported roughly thirty simultaneous users, all physically present at MIT. The password was checked by comparing what you typed against what was stored, character for character, and what was stored was the password itself, in plain text. Given that machine and that population, this was a reasonable decision. It lasted about eight months.

Spring 1962: Allan Scherr and the first leak#

Allan Scherr was a doctoral student at MIT working on the performance of time-sharing systems; he took his PhD there in 1965 and went on to a long career at IBM, becoming an IBM Fellow and a central figure in the MVS operating system. In the spring of 1962 he had a more immediate problem. He had been allocated four hours per week of CTSS time, and his simulations needed more.

CTSS had a facility for requesting that a file be printed offline by submitting a punched card. The request did not check what you were asking for. In Scherr’s own recollection, recorded decades later:

“There was a way to request files to be printed offline by submitting a punched card. Late one Friday night, I submitted a request to print the password files and very early Saturday morning went to the file cabinet where printouts were placed and took the listing.”

He now had every password on the system. He used some of the extra time himself and, by his account, passed the list to others, who logged in as other researchers. He confessed to Robert Fano, the head of the laboratory, roughly twenty-five years afterwards.

Look at the shape of this incident, because it recurs for the next sixty-four years without much variation. The password mechanism was not broken. Nothing was guessed. No cryptography failed. A completely separate feature, offline printing, had access to a file of secrets and no reason to ask whether the requester should see it. In modern language, the password file was a high-value asset with no compartmentalization, reachable through an unauthenticated read primitive in an unrelated subsystem. The first password file was stolen about eight months after the first password was created, by a graduate student who wanted more computer time, using a printer.

1966: the day the password file was the message of the day#

The second famous CTSS incident is stranger, and for the design of everything that followed, more important.

Morris and Thompson tell it in their 1979 paper, in the passage explaining why storing plain text passwords is indefensible:

“Perhaps the most memorable such occasion occurred in the early 60’s when a system administrator on the CTSS system at MIT was editing the password file and another system administrator was editing the daily message that is printed on everyone’s terminal on login. Due to a software design error, the temporary editor files of the two users were interchanged and thus, for a time, the password file was printed on every terminal when it was logged in.”

The mechanism, recorded on the Multicians archive by Tom Van Vleck, who was there, is that the CTSS text editor created its temporary file under a fixed name, so two administrators editing different files at the same time with the same privileges ended up with each other’s temporary files. The account dates the incident to 1966 and to five o’clock on a Friday afternoon; a user named Bill Mathews, seeing passwords scroll past, deliberately crashed the machine to stop it, and Van Vleck spent the evening changing everyone’s password.

Corbato returned to this incident in his ACM Turing Award lecture, “On building systems that will fail”, published in Communications of the ACM, volume 34, number 9, September 1991, pages 72 to 81. His subject there was complexity and failure in general, but the lesson the industry drew was sharper: as long as the system holds your actual password, an ordinary bug in a component with nothing to do with security can publish it.

Note the dating, because the accounts differ. Morris and Thompson wrote “the early 60’s” in 1979; the Multicians account, from a participant, gives 1966, and is the better sourced of the two.

Multics, and the turn to one-way functions#

Multics was the successor to CTSS, begun in 1965 as a joint project of MIT, General Electric and Bell Telephone Laboratories. It is the direct ancestor of Unix in both ideas and personnel, and it is where the password stopped being a stored word.

The idea is simple to state and was hard to have. Do not store the password. Store the result of putting the password through a function that is easy to compute in one direction and infeasible to run backwards. To check a login, apply the function to what was typed and compare the results. The file is then no longer a list of secrets. A one-way function is exactly that: a function cheap to evaluate and, for anyone holding only the output, computationally infeasible to invert.

On Multics the implementation came from Tom Van Vleck, on a suggestion from Joseph Weizenbaum, the MIT computer scientist better known for the ELIZA program. Van Vleck’s own account, on the Multicians archive, is candid about how badly the first attempt went:

“Joe had suggested I store the square of the password, but I knew people could take square roots, so I squared each password and ANDed with a mask to discard some bits.”

Squaring and discarding bits is a reasonable first instinct: multiplying is easy, and throwing away half the result should destroy what is needed to reverse it. It failed for a reason nobody could have designed around. The Multics PL/I compiler had a bug in squaring long integers, producing wrong answers in a predictable way, and attackers who tabulated that behaviour needed only a few hundred trials to invert the transform. The scheme was replaced with a stronger one before the compiler bug was fixed.

Two points of history deserve care. First, one-way ciphering of passwords was in the air in more than one place in the mid-1960s, and attribution is genuinely contested; the Cambridge group around Roger Needham is often credited alongside Multics. [UNVERIFIED: the precise attribution and date of the Cambridge one-way password proposal] Second, the first careful published treatment of the mathematics is George Purdy’s paper “A high security log-in procedure”, Communications of the ACM, volume 17, number 8, August 1974, pages 442 to 445, which proposed a high-degree polynomial over a large prime field as the one-way function, precisely because finding roots is far more expensive than evaluating the polynomial.

By the mid-1970s the design was settled in principle: never store the secret, store its image under a function nobody can invert. What was not settled, and what the next five years established painfully, is that this is nowhere near enough.

1979: what Morris and Thompson actually built#

The single most important document in the history of passwords is four pages long. Robert Morris and Ken Thompson, both of Bell Laboratories, published “Password Security: A Case History” in Communications of the ACM, volume 22, number 11, November 1979, pages 594 to 597. Morris had been at Bell Labs since 1960 and later served as chief scientist of the National Security Agency’s National Computer Security Center from 1986 to 1994; Thompson was the co-creator of Unix. The paper is written as a history rather than a specification, and its opening explains why: “The present design was the result of countering observed attempts to penetrate the system.”

Start with what they inherited. Early Unix stored actual passwords in a protected file, and they give four reasons why that is untenable: the file is exposed while being edited, privileged users can copy it, backup tapes carry it out of the building, and ordinary programs needing user information end up either over-privileged or duplicating data. Their conclusion was to design so that nothing needed protecting from reading at all: “It also seemed advisable to devise a system in which neither the password file nor the password program itself needed to be protected against being read by anyone.”

Their first scheme used the encryption program that happened to be on the machine, a software simulation of the M-209 cipher machine used by the United States Army in the Second World War. They did not encrypt the password. They used it as the key, encrypted a constant with it, and stored the result. Recovering a key given both plaintext and ciphertext was far harder than decrypting a message, so this was a genuine one-way construction built out of an ordinary cipher.

Then they attacked it themselves, and here the paper becomes the founding document of empirical password research. They gathered 3,289 passwords from real users and classified them.

Their summary is the sentence everybody quotes: “A total of 2,831, or 86% of this sample of passwords fell into one of these classes.” The dictionary search alone, they note, “required only five minutes to run” and “produced about one third of the passwords”.

Then comes the anecdote that ought to be read aloud in every design review. At one installation users were not allowed to choose passwords; the system generated them, eight characters long, from lower-case letters and digits. Searching that space exhaustively on the hardware of the day would have taken 112 years. But the generator was a pseudo-random number generator with only 2 to the power 15 possible starting values, which is 32,768. The attacker generated all 32,768 possible outputs, tested them, and “found every one of the system-generated passwords using a total of only about one minute of machine time”. The lesson is exact and permanent: the strength of a generated secret is the entropy of the generator, never the size of the alphabet it draws from.

Their response was four changes, and each answers a specific attack. All four are still present in every serious password system in 2026.

1. Slower encryption. They replaced the M-209 simulation with the newly announced Data Encryption Standard, chosen not only because it is hard to invert but because, in their words, “it is extremely slow when implemented in software”. The first eight characters of the password become the DES key, a constant is encrypted with it, and “the DES algorithm is iterated 25 times and the resulting 64 bits are repacked to become a string of 11 printable characters”. Deliberate slowness as a defence begins here.
2. Less predictable passwords. The password-setting program began pushing back: an all-alphabetic password shorter than six characters, or a mixed one shorter than five, prompted the user to enter a longer one. This is the first password policy, and it is notably gentle. The paper adds, with visible reluctance to coerce, that the user “is not prevented from using his spouse’s name if he wants to”.
3. The salt. When a password is first set, the program reads the real-time clock for a 12-bit random number, appends it to the password, and stores both the random number and the encrypted result: “both the 12-bit random quantity (called the salt) and the 64-bit result of the encryption are entered into the password file.” The word salt is named here. Twelve bits is 4,096 values, so “the work of testing a given character string against a large collection of encrypted passwords has been multiplied by 4096”, and, more importantly, precomputation dies: “it becomes impractical to prepare an encrypted dictionary in advance.”
4. The altered E-table. Hardware DES chips were arriving and were roughly a thousand times faster than software. So they modified one of the internal tables of DES, the E-table, in a way that depends on the salt, deliberately making standard hardware useless: “The E-table is inseparably wired into the DES chip, so that the commercial chip cannot be used.”

There is a fifth change, in a section they call “A subtle point”, and it is the earliest description in the literature of a timing side channel in authentication. When the slow encryption was first added, it ran only if the user name existed, since otherwise there was nothing to compare against. A valid user name therefore produced a delay of about half a second and an invalid one produced an instant response, so an attacker could enumerate user names with a stopwatch. They fixed it by doing the encryption either way. Constant-time authentication responses are a 1979 idea.

The salt has one further consequence, which they noticed and stated in a single sentence, and which the rest of this chapter is arguably about: “It becomes nearly impossible to find out whether a person with passwords on two or more systems has used the same password on all of them, unless you already know that.” They saw reuse coming. What they could not have foreseen is that the answer would one day be handed to attackers directly, in plain text, by the breached sites themselves.

The 1979 table, and how to read it in 2026#

The paper contains a table of exhaustive search times on a PDP-11/70, based on a measured rate of one trial password per 1.25 milliseconds. Here is part of it, reproduced exactly.

Read those 1979 numbers for what they are: 800 guesses per second on a machine that cost about as much as a house. The modern equivalents belong to chapter 14, which measures what a current graphics processor does to each password hashing function; every entry in that table has since fallen by many orders of magnitude, and the left-hand column is now measured in seconds.

What has not changed is the shape of the table. Each extra character multiplies the work by the size of the alphabet; each extra character class multiplies it by far less than people expect. That structure is why length beats complexity, and it was visible in 1979.

Here is the layout that came out of all this, the classic Unix password file entry, which is the single most copied data structure in the history of authentication. The colon-separated fields are the specification; the 13-character password field is 2 characters of salt followed by 11 characters of output.

meera:qLO1JW/feZSFk:1031:50:Meera K:/usr/meera:/bin/sh
      |  |
      |  +-- 11 chars: the 64-bit result, repacked
      +----- 2 chars: the 12-bit salt

Alphabet for both fields: . / 0-9 A-Z a-z  (64 symbols)
Password input: first 8 characters only
DES iterations: 25

That field is a genuine one: it is the output of the traditional Unix crypt function for the password “shikhar1” with the salt “qL”.

Two details in that block are worth stating plainly because they are so often misremembered. The password field is not an encryption of the password; it is an encryption of a constant using the password as a key. And the algorithm silently ignored everything after the eighth character, so a 30-character passphrase on a 1979 Unix system was an 8-character password with decoration.

Entropy: what it is, and how to compute it#

Entropy is a measurement of uncertainty, defined by Claude Shannon in “A Mathematical Theory of Communication”, published in the Bell System Technical Journal in 1948. For a process with outcomes of probability p1, p2 and so on, the Shannon entropy in bits is the sum over all outcomes of minus p times the base-2 logarithm of p. If all N outcomes are equally likely this collapses to the logarithm of N, and one bit is one fair coin flip. For a password recipe that picks characters independently and uniformly, the arithmetic is the number of characters multiplied by the base-2 logarithm of the alphabet size.

from math import log2

def bits(alphabet_size, length):
    return length * log2(alphabet_size)

print(bits(26, 6))     # 28.20  six random lower-case letters
print(bits(62, 8))     # 47.63  eight random letters or digits
print(bits(95, 8))     # 52.56  eight random printable ASCII
print(bits(62, 12))    # 71.45  twelve random letters or digits
print(bits(7776, 4))   # 51.70  four random words from a list
print(bits(7776, 6))   # 77.55  six random words from a list

The 7,776 in that last pair is not arbitrary: it is 6 to the power 5, so five rolls of a die select one word from a published list of that size, which is the construction behind dice-generated passphrases. Notice what the numbers say. Four random common words beat eight random letters and digits, and they are far easier to remember and type. Length over a large alphabet of words is the most efficient way a human can carry real entropy.

Now the other entropy, the one that describes people rather than recipes. Min-entropy is minus the logarithm of the probability of the single most likely outcome, and it answers exactly one question: how well does an attacker do with one guess. It is the pessimistic end of the family of Renyi entropies, and for security work it is usually the honest one.

from math import log2

top   = 290731     # RockYou users who chose "123456"
total = 32603388   # passwords in the RockYou corpus

p1 = top / total   # 0.0089172
print(p1 * 100)    # 0.892 per cent of all accounts
print(-log2(p1))   # 6.81 bits of min-entropy

Read that result slowly. Thirty-two million people, choosing freely with no policy stopping them, produced a distribution whose min-entropy is 6.81 bits. Seven coin flips would have done as well against a one-guess attacker as thirty-two million human beings did.

It is worth seeing how the industry used to estimate this, because the method is still embedded in old software. Appendix A of NIST Special Publication 800-63-2, dated August 2013, gave a heuristic for user-chosen passwords: 4 bits for the first character, 2 bits each for characters 2 to 8, 1.5 bits each for characters 9 to 20, and 1 bit each beyond, with a bonus of up to 6 bits for composition rules and up to 6 for a dictionary check. Apply it to Meera’s Pihu@2019: 4, plus 7 characters at 2 bits, plus one at 1.5, gives 19.5 bits; the composition bonus takes it to 25.5 and the dictionary bonus to 31.5.

That number is a rule of thumb calibrated against the habits of the 2000s, not a measurement. It cannot tell a password an attacker reaches in his first thousand guesses from one he never reaches, because it never looks at what attackers try. NIST removed it in Revision 3 of the guideline in 2017 and did not bring it back in Revision 4. The replacement is not a better formula; it is to check the password against a list of passwords known to have been used.

The honest version: entropy is the right tool for reasoning about generated secrets and the wrong tool for reasoning about chosen ones. For anything a human picked, the only defensible measurement is empirical, and it is a measurement of the attacker, not of the password.

Guessing entropy, and why the attacker does not care about it#

If one number will not do, the natural next idea is an average. Guessing entropy, or guesswork, written G, is the expected number of guesses an optimal attacker needs, sorting the candidates from most to least likely and counting until he arrives at the right one. Formally, G is the sum over all passwords of the rank i multiplied by the probability p sub i.

James Massey showed in 1994, in a short paper called “Guessing and entropy”, that guesswork and Shannon entropy are related only loosely: guesswork is bounded below by roughly one quarter of 2 raised to the Shannon entropy, and there is no useful upper bound at all. A small worked example makes the problem visible.

Take a million accounts. Two per cent use 123456. The other 98 per cent are perfectly random, drawn uniformly from a space of a million million passwords. The head contributes almost nothing to G, namely 0.02 multiplied by 1. The tail contributes 0.98 multiplied by half of a million million, which is 490 thousand million. So G is about 4.9 times 10 to the power 11, or 38.8 bits, and by that measure this is an extremely strong population. Yet one single guess opens twenty thousand accounts.

That is why guessing entropy is the wrong number. It describes the cost of breaking every account, and no attacker wants every account; he wants the cheapest ten thousand, and then he stops, because his economics are throughput and not completeness.

The fix is to stop asking for one number and ask for a curve. Joseph Bonneau set this out in “The Science of Guessing: Analyzing an Anonymized Corpus of 70 Million Passwords”, at the IEEE Symposium on Security and Privacy in 2012. His alpha-work-factor is the expected number of guesses per account needed to reach a success rate of alpha, allowing the attacker to give up on accounts he has already broken; his marginal guesswork is the success rate an attacker achieves when limited to a fixed number of guesses per account.

Bonneau’s corpus was 69,301,337 Yahoo users, measured over 48 hours in May 2011 by an anonymized histogram method that never exposed individual passwords. His headline conclusion is quoted here exactly, because it is the most useful single sentence in the literature: passwords “provide fewer than 10 bits of security against an online, trawling attack, and only about 20 bits of security against an optimal offline dictionary attack”.

“Ten bits of security against online attack” means the population behaves, from a guessing attacker’s point of view, like a uniform choice among about 1,024 possibilities. We can check that against the RockYou data independently. Ten guesses per account reached 2.079 per cent of accounts, an average of 0.2079 per cent per guess, which is the same per-guess success as a uniform distribution over 481 possibilities, or 8.9 bits. Two entirely different corpora, two different populations, one measured in 2009 and one in 2011, land within a bit of each other.

Bonneau’s other finding is less quoted and more disturbing. He could isolate groups within the corpus by age, by language, by nationality, and by whether the user had registered a payment card, and the distributions barely moved: “every identifiable group of users generated a comparably weak password distribution”, and “security motivations such as the registration of a payment card have no greater impact than demographic factors such as age and nationality”. People who have money at stake choose almost exactly as badly as people who do not.

The shape of human choice: Zipf’s law in passwords#

The distributions above are not arbitrary. They have a shape, and the shape has a name.

George Zipf observed in 1949, in “Human Behavior and the Principle of Least Effort”, that word frequencies in natural language follow a simple rule: a word’s frequency is roughly inversely proportional to its rank, so the most common word appears about twice as often as the second and three times as often as the third. Written as a formula, the frequency f of the item at rank r equals a constant C divided by r raised to a power s.

Password choices follow the same kind of law. The clearest published fit is by Ding Wang and colleagues in “Zipf’s Law in Passwords”, IEEE Transactions on Information Forensics and Security, volume 12, number 11, 2017, with the fitted numbers also in the 2014 preprint of the same work. They fitted the popular region of each corpus, meaning passwords appearing at least five times.

The fit quality column is the coefficient of determination, which reaches 1.0 for a perfect straight line on a log-log plot; 0.994 and above is, for social data, remarkably good. Two corpora from different countries, languages and services produce almost the same exponent.

Three consequences follow, and they are the practical core of this chapter.

First, the head is fat and the tail is long. A slope slightly below 1 means the most popular passwords carry a disproportionate share of users, which is why ten guesses buy two per cent of accounts. It also means the number of distinct passwords keeps growing almost linearly with the number of users, so no finite dictionary covers everybody. Attackers do not want to cover everybody.

Second, blocklists work better than intuition suggests. If a small number of passwords carry a large share of users, forbidding that small number removes a large share of total risk at almost no cost in usability. This is why modern standards require a blocklist and forbid composition rules: the blocklist attacks the fat head, and composition rules mostly reshuffle it.

Third, the honest caveat the fitted line itself provides: do not extrapolate it. Applied at rank 1, the RockYou fit predicts 819,147 users choosing the most popular password, where the true number was 290,731, an overshoot of 2.8 times. The authors fit only the region at or above frequency five, and later work by the same group introduced a cumulative form of the model precisely because the simple form fits the whole distribution badly. Experts do not fully agree that password distributions are true Zipf distributions rather than Zipf-like over part of their range. The skew is not in dispute, and the skew is what the attacker exploits.

Reuse is the vulnerability, not strength#

Everything so far has been about guessing. Now we come to the part that actually loses accounts, and where the intuitive advice fails hardest. Start with how much reuse there is: four independent measurements, four different methods, over eleven years.

Anupam Das, Joseph Bonneau, Matthew Caesar, Nikita Borisov and XiaoFeng Wang published “The Tangled Web of Password Reuse” at the Network and Distributed System Security Symposium in February 2014. From several hundred thousand leaked passwords across eleven web sites plus a user survey, they estimated that 43 to 51 per cent of users reuse the same password across multiple sites. They then built the first cross-site password guessing algorithm, which takes a user’s known password from one site and predicts their password at another by applying the small edits people actually make. It guessed 30 per cent of non-identical password pairs within 100 attempts and 10 per cent within 10, against 14 per cent for a conventional guesser with no cross-site knowledge. Changing Pihu@2019 to Pihu@2020 for the bank is not a defence; it is a hint.

Sarah Pearman and colleagues at Carnegie Mellon published “Let’s Go in for a Closer Look: Observing Passwords in Their Natural Habitat” at the ACM Conference on Computer and Communications Security in 2017. Instead of asking people, they instrumented the browsers of 154 participants for an average of 147 days each and watched. The average participant used 9.88 distinct passwords across 26.34 web domains; 32 per cent of the unique passwords observed were exactly reused somewhere, 53 per cent showed partial reuse, and about 60 per cent showed reuse of some kind. Their most uncomfortable finding is that stronger passwords were not reused less; passwords containing digits and symbols were reused slightly more, because a password that satisfies many sites’ composition rules is convenient everywhere.

Kurt Thomas and colleagues at Google published “Data Breaches, Phishing, or Malware? Understanding the Risks of Stolen Credentials” at the same 2017 conference, and their measurement turns reuse into a number an attacker can bank. Between March 2016 and March 2017 they collected 1.9 billion credentials traded on criminal forums, identified 751,133,653 Google users appearing in that data, and checked how many of the leaked passwords still worked on the Google account. The answer was 51,754,113, a match rate of 6.9 per cent. For victims of phishing kits the rate was 24.8 per cent, and for keylogger victims 11.9 per cent. In the same data, 17.0 per cent of the 22 million addresses appearing in more than one leak had reused a password at least once, which is a hard lower bound on reuse rather than a survey estimate.

That 6.9 per cent is the single most useful number in this chapter, and it needs one sentence of interpretation. It is not a measure of how weak passwords are: every one of those 51 million passwords could have been 20 random characters and the rate would have been identical, because nothing was guessed. It measures how often a password stolen from one place is still the password somewhere else.

The most recent of the four measurements is the Verizon Data Breach Investigations Report of 2025, which studied credentials harvested by information-stealing malware. In the median case across 14,742 infections, only 49 per cent of a user’s passwords were distinct from one another, and compromised credentials were the initial access route in 22 per cent of the breaches the report reviewed.

Finally, the deployment measurement. Kurt Thomas and colleagues reported on Google’s Password Checkup extension in “Protecting accounts from credential stuffing with password breach alerting” at USENIX Security in 2019. Across nearly 670,000 users and 21 million logins, 316,531 logins, or 1.5 per cent, used a credential already known to be breached; when warned, 26 per cent of users changed the password.

The conclusion is not subtle. One login in every sixty-six across the ordinary web is made with a password an attacker already holds in a file. Strength is not what is failing. Uniqueness is.

Credential stuffing, with the arithmetic#

Now we can do the sum properly. Credential stuffing needs three ingredients: a corpus of stolen pairs, a list of targets, and a way to make many login attempts without being blocked. The corpora are public, large and mostly free. Here are three, with the figures published by the people who counted them.

Collection #1, analysed by Troy Hunt of the Have I Been Pwned service on 16 January 2019, was 87 gigabytes in more than 12,000 files, containing 2,692,818,238 rows which reduced to 1,160,253,228 unique combinations of email address and password, 772,904,991 unique addresses, and 21,222,975 unique passwords. Notice the shrinkage: 2.7 billion rows contain only 21 million distinct passwords, because the same passwords appear over and over.

The Synthient corpus, loaded into the same service on 5 November 2025, came from credential-stuffing and information-stealer collections and contained 1,957,476,021 unique email addresses and about 1.3 billion unique passwords, of which 625 million had never been seen in that service’s corpus before.

Here is the honesty note this section needs. In 2025 a widely reported story announced a breach of 16 billion passwords. When Troy Hunt obtained and processed the underlying data, it came to 2.7 billion rows in 775 gigabytes, parsing down to 325 million records and 109 million unique email addresses, of which 4.4 million had never been seen before; 96 per cent of the passwords were already in the corpus. The headline was a count of lines in recycled files. Treat every breach headline as a count of rows until someone tells you it is a count of people.

The pipeline looks like this.

  breach at site A          infostealer on a laptop
        |                            |
        +------------+---------------+
                     v
            combo list (email:password)
                     v
        deduplicate, filter by domain
                     v
   +-----------------------------------------+
   |  stuffing tool + proxy pool (many IPs)   |
   +-----------------------------------------+
                     v
        login endpoint at site B, C, D ...
                     v
     valid session  ->  drain / resell / phish

Now the worked example, carried on from the plain version.

Meera’s grocery delivery service has 8,000,000 registered accounts, each identified by an email address. The attacker holds a corpus of the size described above. Two numbers turn that into a result.

The first is overlap: what share of the site’s users appear anywhere in the corpus. For a consumer service in a market where the corpus already holds nearly two billion addresses, an overlap of 45 per cent is a reasonable working figure, stated here as an assumption rather than a measurement. That gives 3,600,000 candidate pairs.

The second is the hit rate: what share of those pairs still open the account. We have a measured figure for exactly this quantity, 6.9 per cent, from the Google study described above. It is the best public estimate available and it comes from a large, well-defended provider, so treat it as an estimate rather than a law of nature.

users at target            8,000,000
overlap with corpus (est.)      45%  -> 3,600,000 pairs
hit rate (measured, 2017)      6.9%  ->   248,400 accounts
                                          = 3.1% of the site

Two hundred and forty-eight thousand accounts. Now the cost. Suppose the attacker rents a residential proxy pool of 5,000 addresses and runs slowly, one request per address every five seconds, below the rate at which most defences notice anything. That is 1,000 requests per second, so 3,600,000 attempts take 3,600 seconds: one hour. At roughly 1.5 kilobytes per request and response, the campaign moves about 5.4 gigabytes, less traffic than a single film.

An hour, five gigabytes, no cryptography, no vulnerability, no exploit, and nothing any strength meter would have flagged. That is why this is the dominant attack, and a single attempt looks completely ordinary from the server’s point of view.

POST /api/v2/login HTTP/1.1
Host: shop.example.in
Content-Type: application/json
User-Agent: Mozilla/5.0 (Linux; Android 14)
X-Forwarded-For: 203.0.113.47

{"email":"meera@example.com","password":"Pihu@2019"}

HTTP/1.1 200 OK
Set-Cookie: sid=8f2b...; HttpOnly; Secure; SameSite=Lax

Nothing in that exchange is anomalous: one request, from a residential address, with a valid password, succeeding. Every signal available to the defender is statistical and lives above the level of the single request.

Now map defences onto the terms of the arithmetic, because this is where most security spending goes wrong.

1. Locking an account after five failures changes nothing. The attacker makes one attempt per account.
2. Rate limiting per network address changes the time, not the result. Five thousand addresses divided the work; fifty thousand would divide it further.
3. Requiring more complex passwords changes nothing at all. Complexity affects guessing, and nothing here is being guessed.
4. Forcing periodic changes helps only if the change falls between the theft and the attempt, and users respond with the predictable edits the 2014 cross-site guesser was built to exploit.
5. Checking new passwords against a corpus of breached ones attacks the hit rate directly, because it removes exactly the credentials the attacker holds.
6. Requiring a second factor attacks the value of a valid password, which is the only term that goes to zero.
7. Detecting the campaign rather than the request, using failure rates per endpoint, address diversity and the ratio of unknown to known accounts, is what stops a run in progress.

For scale, Akamai reported 193 thousand million credential stuffing attempts against its customers during 2020, up from 47 thousand million in 2019, in its State of the Internet security report published in 2021. F5, which sells defences against this, gives a typical success rate of 0.2 to 2 per cent per campaign; treat that as a vendor figure rather than a peer-reviewed one. The Verizon 2025 report found that across 2,301 organizations using a single sign-on provider, credential stuffing was a median 19 per cent of all authentication attempts on a typical day, rising to 25 per cent for enterprises, with a peak single-day observation of 44 per cent.

Roughly one login attempt in five arriving at a typical enterprise is an attacker trying a stolen password. That is the load-bearing wall of the internet in 2026.

What a password verifier is required to do, as of August 2026#

The rules changed, and they changed in the direction the research had been pointing for twenty years.

NIST Special Publication 800-63B, Revision 4, “Digital Identity Guidelines: Authentication and Authenticator Management”, was published in July 2025 and is a standard in the sense that United States federal agencies are bound by it and much of the world’s industry follows it voluntarily. Its requirements for passwords, which it calls memorized secrets, are in section 3.1.1.2. The important ones, in its own normative language:

1. Verifiers and credential service providers SHALL require passwords used as a single-factor authentication mechanism to be a minimum of 15 characters; passwords used only as part of multi-factor authentication MAY be shorter but SHALL be at least 8 characters.
2. Verifiers SHOULD permit a maximum password length of at least 64 characters, SHOULD accept all printing ASCII characters and the space, and SHOULD accept Unicode, counting each code point as one character.
3. Verifiers SHALL NOT impose composition rules, such as requiring a mixture of character types.
4. Verifiers SHALL NOT require periodic password changes, and SHALL force a change only when there is evidence of compromise.
5. Verifiers SHALL compare a prospective password against a blocklist of known commonly used, expected or compromised values, comparing the entire password and not substrings, and SHALL tell the user why a password was rejected.
6. Verifiers SHALL NOT permit password hints accessible to an unauthenticated party, and SHALL NOT use security questions.
7. Verifiers SHALL implement rate limiting on failed authentication attempts.
8. Verifiers SHALL allow the use of password managers, and SHOULD permit pasting into the password field.

The 15-character minimum for a password standing alone is the newest and most contested of these; Revision 3, published in 2017, set the floor at 8. The direction of travel is clear enough: if the password is the only thing between an attacker and the account, it has to carry weight that a short one cannot.

Two of these deserve a note on why. Forbidding composition rules is not laxity; it follows the finding, repeated in every study cited here, that such rules push users towards a small set of predictable transformations without adding real unpredictability. Forbidding scheduled expiry reverses thirty years of near-universal practice, on the evidence that forced changes produce small predictable edits and drive passwords onto paper.

The blocklist requirement needs a mechanism, and here convention rather than standard takes over. The usual implementation checks a candidate against a corpus of breached passwords without sending the password anywhere, using a technique called k-anonymity. The client hashes the password with SHA-1, sends only the first five hexadecimal characters of the hash, and receives every stored suffix beginning with those characters together with a count of how often each has been seen. The comparison happens locally.

GET /range/F3BBB HTTP/1.1
Host: api.pwnedpasswords.com

HTTP/1.1 200 OK
Content-Type: text/plain

D66A63D4BF1747940578EC3D0103530E21D:<count>
D6B0DE6D6E4D3B7B4C7E0C0B0EEF6E58ADA:<count>
... several hundred more suffixes ...

The full SHA-1 of the string hunter2 is f3bbbd66a63d4bf1747940578ec3d0103530e21d, so F3BBB is all the service ever learns, and that prefix is shared with roughly a million other passwords. This is an implementation detail of one widely used service rather than a standard, but it is the pattern nearly everyone copies, and the corpus is downloadable for services that prefer to hold it themselves. In December 2021 that corpus stood at 847,223,402 distinct passwords representing 5,579,399,834 observed occurrences, and it has grown substantially since, including 625 million additions in November 2025 alone.

One line on the regulatory side, since this book is written from India. The Reserve Bank of India required an additional factor of authentication for card-not-present transactions from its notification of 18 February 2009, which is why an Indian card payment has not been protected by a password alone for more than fifteen years. Chapter 12 handles the factor taxonomy behind such rules, and later chapters in this volume deal with the authenticators now replacing the password outright.

Where does that leave the password in August 2026. It is a shared secret, sixty-five years old, designed to keep colleagues out of each other’s files on a machine with thirty terminals, and it is still the primary authenticator for the large majority of accounts on the internet. The research community has known since 1979 that people choose from a tiny, skewed distribution; since 2012 that the distribution is worth under 10 bits against an online attacker; and since 2017 that roughly 7 per cent of stolen credentials still work somewhere else. The standards finally match the research. The deployed systems are catching up slowly, and the wall holds, mostly, because it is propped up on every side by second factors, breach corpora, rate limits and fraud detection that the original design never imagined and cannot replace.

13.98 Common wrong ideas#

Wrong: A long, complex password protects you. Right: Length and complexity protect against guessing only, and do nothing against a breach at a site where you used that password; Google measured in 2017 that 6.9 per cent of credentials stolen from third parties still opened the user’s Google account.

Wrong: Passwords are hashed now, so a breach is not serious. Right: Hashing turns a breach from a list of secrets into a list of puzzles, and the weakest few per cent of those puzzles fall almost immediately, which is exactly the population an attacker wants; how bad it gets depends on the storage choices covered in chapter 14.

Wrong: My password has 60 bits of entropy. Right: Entropy measures the process that generated a password, not the password itself, so the claim only means something if a random generator produced it; for a human choice the meaningful measurement is how early an attacker’s list reaches it.

Wrong: Changing passwords every 90 days improves security. Right: Scheduled expiry drives users to predictable edits such as an incrementing digit, which cross-site guessers exploit, and NIST SP 800-63B Revision 4 states that verifiers shall not require periodic change, only a change on evidence of compromise.

Wrong: Requiring an upper case letter, a digit and a symbol makes passwords stronger. Right: Composition rules mostly move users to a few predictable patterns, such as capitalizing the first letter and appending 1, which is why the same standard forbids imposing them.

Wrong: Locking an account after five failed attempts stops password attacks. Right: It stops one attacker guessing many passwords against one account, the rarest case; credential stuffing makes a single attempt per account and spraying tries one common password across every account, so neither reaches a per-account limit.

Wrong: The salt is secret and protects the password. Right: The salt is stored in the clear beside the hash and was never secret; its purpose, as stated when Morris and Thompson named it in 1979, is to make precomputed dictionaries useless and to stop one guess being tested against many accounts at once.

Wrong: A breach of 16 billion passwords means 16 billion new victims. Right: Headline breach figures usually count rows in files rather than people, and when that 2025 corpus was actually processed it yielded 109 million unique addresses of which 4.4 million were new, with 96 per cent of the passwords already known.

Wrong: Passwords are obsolete and should simply be abolished. Right: The password is still the only authenticator that costs nothing to issue, needs no hardware, survives the loss of every device and depends on no manufacturer, so the practical goal is to stop relying on it alone rather than to remove it.

13.99 Chapter summary in 20 lines#

1. A password is a shared secret, and every weakness of it follows from the fact that the service must hold it too.
2. CTSS at MIT, demonstrated in November 1961 under Fernando Corbato, is credited with the first password login, added to keep colleagues’ files apart rather than to defeat an adversary.
3. Allan Scherr printed the whole CTSS password file in the spring of 1962 by submitting a punched card requesting an offline print.
4. In 1966 a fixed temporary file name in the CTSS editor caused the password file to be printed as the message of the day on every terminal.
5. Multics answered that by storing a one-way transformation instead of the password, implemented by Tom Van Vleck and defeated at first by a compiler bug in squaring long integers.
6. George Purdy’s paper in Communications of the ACM in August 1974 gave the first careful mathematical treatment of a one-way login procedure.
7. Robert Morris and Ken Thompson published “Password Security: A Case History” in Communications of the ACM, volume 22, number 11, November 1979.
8. They found that 2,831 of 3,289 real passwords, or 86 per cent, fell into a few trivially searchable classes.
9. Their four fixes were slow encryption, a gentle length policy, a 12-bit salt that killed precomputed dictionaries, and an altered DES table that defeated commercial hardware.
10. They also fixed the first documented authentication timing side channel, by encrypting even when the user name did not exist.
11. Entropy measures a generating process rather than a chosen password, and for a uniform recipe it is the length times the base-2 logarithm of the alphabet size.
12. Four random words from a list of 7,776 give 51.7 bits, beating eight random letters and digits at 47.6 bits.
13. In the RockYou corpus of 32,603,388 passwords, 290,731 users chose 123456, giving the population a min-entropy of 6.81 bits.
14. Guessing entropy is the wrong measure because it is dominated by the hardest accounts while attackers stop early.
15. Bonneau’s 2012 study of 69,301,337 Yahoo passwords found fewer than 10 bits of security against online guessing and about 20 bits against offline attack.
16. Password frequencies follow a Zipf-like power law with an exponent near 0.91 in both the RockYou and Tianya corpora, which is why small blocklists work.
17. Between 43 and 51 per cent of users reuse passwords across sites, and the small edits between sites are predictable enough that 30 per cent of non-identical pairs fall within 100 guesses.
18. Google measured that 6.9 per cent of credentials exposed in third-party breaches still opened the victim’s Google account, rising to 24.8 per cent for phishing victims.
19. A stuffing campaign against a site with eight million users, at 45 per cent overlap and that hit rate, opens about 248,400 accounts in an hour for 5.4 gigabytes of traffic.
20. NIST SP 800-63B Revision 4, published in July 2025, requires a 15-character minimum for a standalone password, forbids composition rules and expiry, and requires a breach check.

Chapter sources: Robert Morris and Ken Thompson, “Password Security: A Case History”, Communications of the ACM, volume 22, number 11, November 1979, pages 594 to 597, for the M-209 and DES schemes, the 25 iterations, the 12-bit salt, the altered E-table, the 3,289-password survey and the PDP-11/70 search-time table; Fernando Corbato, “On building systems that will fail”, ACM Turing Award lecture, Communications of the ACM, volume 34, number 9, September 1991, pages 72 to 81; Corbato’s account of the origin of the CTSS password and Allan Scherr’s recollection of the punched-card print request, as reported by Robert McMillan in January 2012 and drawn from “The Compatible Time-Sharing System (1961-1973): Fiftieth Anniversary Commemorative Overview”, edited by David Walden and Tom Van Vleck, IEEE Computer Society, 2011; the Multicians archive pages of Tom Van Vleck for the 1966 password file incident and the Multics squaring one-way function; George B. Purdy, “A high security log-in procedure”, Communications of the ACM, volume 17, number 8, August 1974, pages 442 to 445; Claude Shannon, “A Mathematical Theory of Communication”, Bell System Technical Journal, 1948, and James Massey, “Guessing and entropy”, IEEE International Symposium on Information Theory, 1994; Joseph Bonneau, “The Science of Guessing”, IEEE Symposium on Security and Privacy, 2012; Ding Wang and colleagues, “Zipf’s Law in Passwords”, IEEE Transactions on Information Forensics and Security, volume 12, number 11, 2017, with the 2014 preprint for the fitted exponents 0.912453 and 0.905773; the Imperva white paper “Consumer Password Worst Practices”, 2010; Das, Bonneau, Caesar, Borisov and Wang, “The Tangled Web of Password Reuse”, NDSS, February 2014; Pearman and colleagues, “Let’s Go in for a Closer Look”, ACM CCS, 2017; Thomas and colleagues, “Data Breaches, Phishing, or Malware?”, ACM CCS, 2017, and “Protecting accounts from credential stuffing with password breach alerting”, USENIX Security, 2019; Troy Hunt’s analyses of Collection #1 of 16 January 2019, the Synthient corpus of 5 November 2025, the Pwned Passwords totals of December 2021 and the 2025 examination of the “16 billion password” claim; the Verizon Data Breach Investigations Report 2025; Akamai’s State of the Internet security report of 2021; NIST Special Publication 800-63-2, August 2013, Appendix A, and NIST Special Publication 800-63B Revision 4, July 2025, section 3.1.1.2; and the Reserve Bank of India notification of 18 February 2009 on additional factor of authentication for card-not-present transactions.