xkcd 936 Is Both Right and Wrong About Password Entropy

There is a slightly unsettling thing about password security that people do not always appreciate at first: you are not only protecting your password at the login prompt. In practice, you are also protecting whatever representation of that password a service stores — usually a hash, ideally with a salt and a deliberately slow password-hashing algorithm.

That distinction matters a lot.

If an attacker is going through a normal login form, the site can rate-limit them. It can slow them down, lock them out, flag abuse, or require additional checks. But if a site gets hacked and the attacker walks away with the password hashes, the game changes completely. Now they can attack those hashes offline, on their own hardware, with no API limits in the way.

This is part of why I think xkcd 936 is both neat and a little misleading when people repeat it too casually. The comic made an important and helpful point: length and memorability can beat annoying composition rules. But the way many people cite it today turns a useful rule of thumb into something closer to a myth.

The real lesson is not “four words equals 44 bits, therefore you are safe.” The real lesson is that password entropy is about the attacker’s uncertainty, and that uncertainty depends heavily on what the attacker thinks people are likely to do.

What xkcd 936 gets right

The comic was a great corrective to a bad security culture.

For years, people were pushed toward passwords like Tr0ub4dor&3: a normal word with some predictable substitutions, one capital letter, and a symbol bolted on. On paper, that looked “complex.” In reality, attackers know that people make exactly those kinds of changes, so password crackers are built to try them first.

The comic’s alternative — something like correct horse battery staple — made two strong points:

  1. Longer secrets are generally better.
  2. Memorable secrets are more usable than awkward ones.

That is still true. A good passphrase can absolutely be a better user choice than a shorter, mangled pseudo-random-looking password that people forget, reuse, or write down insecurely.

So the comic deserves credit. It improved the conversation.

Where the comic gets overextended

The part that tends to get overstated is the “44 bits of entropy” claim.

That number comes from a very specific model: four words, chosen uniformly at random, from a fixed list of 2,048 words. If those assumptions hold, the math is straightforward:

  • 2,048 possible choices for word one
  • 2,048 for word two
  • 2,048 for word three
  • 2,048 for word four

That gives 2048^4, which is 2^44, or about 17.6 trillion combinations.

So far, so good.

But that does not mean every four-word phrase a human invents has 44 bits of entropy. It only means a password generated by that exact random process has 44 bits of entropy.

And that is where people often slide from “a passphrase generated this way” to “any passphrase that looks kinda like this.”

Those are not the same thing.

Entropy is not magic dust inside the password

Entropy is often spoken about as if it were an inherent property of the string itself. It is not. It is a measure of how uncertain the attacker is.

That means the same password can have very different effective strength depending on the attack model.

For example:

  • If the attacker assumes the password is a totally random string of characters, they may search a huge space.
  • If the attacker assumes the password is four dictionary words, they will search that much smaller space first.
  • If the attacker assumes the user picked the words themselves, they may search an even smaller space made of common nouns, familiar phrases, and semantically plausible combinations.

That last point is the big one.

Humans are bad at being random. If you ask someone to “pick four random words,” they usually do not sample uniformly from a dictionary. They choose familiar, concrete, and often vaguely related words. Attackers know this. They do not need to test every possible string in the universe; they need to test the strings people are likely to choose.

So yes: four words is usually much better than one weak word. But no: that does not automatically grant the full idealized entropy figure people love to quote.

Online attacks and offline attacks are completely different worlds

A lot of confusion around password strength comes from mixing together two very different threats.

1. Online guessing

This is the classic “try logging in over and over” attack.

Here, rate limits matter. Lockouts matter. IP throttling matters. CAPTCHA, abuse detection, and MFA matter. Against a real login system with sane defenses, attackers usually only get a small number of guesses before being slowed or stopped.

In that setting, even a mediocre password may survive far longer than the raw math would suggest, simply because the attacker cannot guess very fast.

2. Offline cracking

This is what happens after a breach, when attackers steal password hashes.

Now the defender’s rate limit is gone. The attacker can guess as fast as their hardware and the hashing scheme allow.

That is why “but the login page is rate-limited” is not the whole story. If the database is breached, the attack no longer goes through the login page.

This is also why password storage matters so much.

Why hashes and salts matter

A password hash is a one-way transformation of the password. The server stores the hash, not the plaintext password. When you log in, your password is hashed again and compared to the stored value.

A salt is an additional random value stored alongside the password hash and mixed into the hashing process. Salts are extremely important, but they do not make a weak password unguessable.

What salts do is:

  • stop attackers from using precomputed rainbow tables effectively,
  • force them to crack each hash separately,
  • and prevent identical passwords from producing identical stored hashes.

That is a big improvement, but it does not remove the need for a strong password.

The other crucial piece is the hashing algorithm itself.

A fast general-purpose hash like SHA-256 is not appropriate for password storage. Modern password hashing should use deliberately slow, adaptive, and ideally memory-hard algorithms such as Argon2id, scrypt, or bcrypt. The point is to make each guess expensive.

That cost is what stands between “a breach is bad” and “a breach instantly turns into mass account compromise.”

So what about the “44 bits only takes two minutes” point?

This is the important caveat: that kind of estimate is only true in the right context.

If an attacker is performing an offline attack against a fast hash and can test on the order of tens or hundreds of billions of guesses per second, then a 44-bit search space really is not that large anymore. In that world, “550 years” collapses fast. A full 2^44 space is about 17.6 trillion guesses. At roughly 100 billion guesses per second, that is on the order of a couple of minutes worst-case, or about half that on average.

That is a dramatic illustration, and it is useful — but only for fast offline cracking scenarios.

It is not the right estimate for:

  • an online login form with rate limiting,
  • a site using a modern slow password-hashing algorithm properly,
  • or a passphrase whose actual search space is different from the simple 4-word model.

So the “two minutes” line is not wrong as a warning. It just needs context.

Does adding a number or symbol help?

Yes — but only if it meaningfully changes what the attacker has to try.

If everyone takes a phrase and appends 1!, that is not much help. Attack tools already try common mutations like:

  • capitalizing the first letter,
  • adding a number at the end,
  • swapping a for @,
  • or adding punctuation like !.

But if you introduce variation in a less predictable way — for example, inserting a number in an unexpected position, or combining a randomly generated passphrase with a truly random extra element — you can force the attacker out of a simple “four words from a list” search and into a broader, more expensive attack.

So the intuition is right: a small extra twist can help a lot. The nuance is that predictable twists help much less than people think.

The best takeaway from xkcd is still not a bad one

Despite all the caveats, I do not think the comic’s core message should be discarded.

The useful part is this:

  • avoid obvious, common passwords,
  • do not rely on shallow composition tricks,
  • prefer length,
  • prefer memorability when you must remember it,
  • and think in terms of realistic attack behavior rather than checklist-style “complexity.”

That is still good advice.

It just needs to be paired with a more mature understanding:

  • entropy depends on the generation process, not just the finished string,
  • attackers optimize their guesses around human behavior,
  • online and offline attacks are very different,
  • and password storage practices on the server side matter enormously.

Practical advice

If you want the short version of what to actually do:

  1. Use a password manager and let it generate long, unique passwords for each site.
  2. If you need a memorable passphrase, generate it randomly rather than inventing it yourself.
  3. More words are better if they are truly random.
  4. A small random extra element can help, especially if it is not a cliché mutation.
  5. Do not reuse passwords, because one breach turns into many compromised accounts.
  6. Use MFA where possible.
  7. Hope the site stores passwords correctly — with salts and slow password-hashing algorithms like Argon2id, scrypt, or bcrypt — because that dramatically changes what attackers can do after a breach.

Final thought

xkcd 936 is best understood as a useful corrective, not as the final word on password strength.

It was right to mock brittle password rules and right to highlight the value of length and usability. Where people go wrong is treating its toy model as universal.

The strength of a password is not a mystical number baked into the string forever. It is a property of the password plus the way it was chosen plus the way it is stored plus the kind of attack being attempted.

That is the part worth remembering.

AI Disclaimer / Transparency:

This article was written by Gemini and GPT, after thinking about this concept for a while, finding some references for my idea, and having them collaborate as agents on creating a blog post about it (reviewing back and forth to make sure the assertions are correct). If you find any inaccuracies, feel free to reach out. As far as I can tell it’s 100% correct, though; It’s simply explaining why Entropy is a messy subject, and it depends entirely on you and the attacker’s methods how much complexity/entropy your password really ends up having.

Updated: