One Leaked List Changed Password Advice, and the Party Doing the Work Is Not You

In December 2009, a social gaming company called RockYou was breached through an ordinary SQL injection, and the attacker walked out with a database of user credentials that had been stored as plain readable text, with no hashing and no salting of any kind. The list was published. Millions of real passwords, chosen by real people for a real site, became available to anyone who wanted to study them. Until that moment, almost everything the security field believed about how people build passwords rested on surveys, laboratory experiments, and the assumptions of the people writing the rules.

What a plaintext list showed that a survey never could

Researchers had long suspected that composition rules produced predictable results, but suspicion is not evidence, and vendors kept shipping the same requirement sets. The RockYou corpus settled the argument by showing what users do when told to satisfy a rule rather than resist an attacker. They capitalize the first letter. They put the digit at the end. They append an exclamation point because the field demands a symbol, and they reuse the same stem across every account they hold. The distribution was steep, concentrated, and easy to model, which is exactly what a password guessing program needs.

That single dataset became the backbone of a decade of academic work on guessing resistance, and it also became a standard wordlist inside the tools attackers use, which is the uncomfortable symmetry of the whole business. Once you can measure how people actually behave, you can measure how well a rule performs. The rules performed badly. Requiring a symbol shifted the population from one narrow set of guesses to a slightly different narrow set, and forcing a change every ninety days moved people from one predictable stem to the same stem with the month incremented.

The party in the transaction almost nobody names

Password advice is written as though the transaction has one participant, the person typing, and as though every failure is a failure of personal discipline. There is a second party, and it holds most of the levers. In the language of digital identity, it is the verifier: the site, the app, the payroll portal, the pharmacy account, the entity that decides what you are allowed to choose, how it stores what you chose, how many times an attacker may guess before the door closes, and what happens when someone calls the help desk claiming to be you. The RockYou breach was not a user failure at all. Every password in that file could have been long, unique, and random, and the outcome would have been identical, because the failure was storage.

This is the part that reframes the whole subject. When your password appears in a dump, the usual explanation offered to you is that you picked something weak, when the far more common cause is that a company you transacted with once kept your credential in a form it should not have kept, or never noticed a script guessing at its login endpoint for three weeks. The National Institute of Standards and Technology, which is responsible for the federal government's digital identity guidance and whose recommendations travel well beyond federal systems, revised its approach in the years after these dumps became public, and the revision put obligations where the evidence pointed. Most of them landed on the verifier.

What moved onto the site's side of the ledger

The visible change, and the one users noticed, was subtraction. Mandatory composition rules went away, because they buy predictability rather than strength. Routine expiration went away, because forced rotation degrades the passwords people choose and trains them to make the smallest possible edit. Knowledge-based questions, the mother's maiden name and the first car, lost their standing entirely, since the answers are either public record or shared across every site that asks. Blocking paste into the password field was recognized as counterproductive, because it is the single most direct way to stop someone from using a manager that generates long random strings.

The additions are less visible and considerably more work. A verifier following current thinking checks a proposed password against a list of values known to have appeared in breaches, dictionaries, and predictable patterns, and rejects the matches instead of insisting on an uppercase letter. It permits long passphrases, which means storing and comparing them rather than truncating at sixteen characters. It throttles and monitors failed attempts, so that an offline-quality guessing rate cannot be achieved online. It hashes with a function designed to be slow and memory-hungry, with a unique salt per user, so that a stolen database is expensive rather than immediately readable. It offers a second factor and does not undo it with a help desk that resets on a birthday.

Reading the label against the practice

You cannot audit any of this from the outside, but the signup form leaks a surprising amount. A site that still demands one uppercase, one number, and one symbol, caps you at twelve characters, blocks paste, and asks for the name of your elementary school is telling you plainly which decade its authentication stack is from, and by extension how much attention the rest of it has had. A site that accepts a sixty-character passphrase, rejects it if it recognizes the string from a breach corpus, offers an authenticator app or a passkey, and shows you a session list with device and location is telling you something else. Neither is proof. Both are evidence, and evidence is what you have.

The label problem is worth naming, because the word secure appears on marketing pages with no definable content behind it, while the substantive claims tend to be specific and dull. Breach screening at registration. Bank-grade is not a standard; a named hashing function with published parameters is. Where the practical difference shows up for you is in the aftermath of somebody else's breach: an account protected by a unique random string and a hardware-backed second factor survives a dump intact, because the stolen value opens nothing else and unlocks nothing on its own.

What that leaves you to do

The user-side work has narrowed to a short list that has held up well. Make every password unique, which means a manager, because the human memory cannot do it. Make the ones you type by hand long rather than clever, since length beats character variety at every meaningful threshold. Turn on a second factor everywhere it exists, and prefer an app or a passkey over text messages when the choice is offered. Stop changing anything on a schedule, and change immediately on evidence: a breach notice, a login alert you do not recognize, a support call you did not place.

The rest of it belongs to the other party, and the direction of travel over the past fifteen years has been steadily toward making that explicit. Passkeys carry the idea to its conclusion by removing the shared secret from the transaction entirely, so there is nothing in the database worth stealing. That is the same lesson RockYou taught, arriving from the other end.