I was stumbling around and happened onto this essay by Bruce Schneier claiming that the XKCD password scheme was effectively dead.

Modern password crackers combine different words from their dictionaries: [...]

This is why the oft-cited XKCD scheme for generating passwords -- string together individual words like "correcthorsebatterystaple" -- is no longer good advice. The password crackers are on to this trick.

The attacker will feed any personal information he has access to about the password creator into the password crackers. A good password cracker will test names and addresses from the address book, meaningful dates, and any other personal information it has. [...] if your program ever stored it in memory, this process will grab it.

His contention seems to be that because it's known that people might construct their passwords in such a way that it makes it amenable to attack, but it seems like the strength lies purely in the power of exponents. I assume he's alluding to people not choosing the words truly randomly, which perhaps isn't totally disingenuous, as I've rerolled a couple times to get something that isn't all adverbs and adjectives. However, I assume that lowering the entropy by a factor of 2-10 isn't really significant (if the word list is doubled to 4000, not that hard, the loss is more than recovered).

The other quip about "if your program ever stored it in memory" is a bit disconcerting though...aren't all passwords stored in memory at one time or another? That seems a bit overbroad; what is he actually referring to?

  • 9
    A discussion with 123 comments about this is on reddit.com/r/technology/comments/1yxgqo/…
    – Dick99999
    Commented Jul 10, 2014 at 7:20
  • 18
    On mouseover, the image title reveals - "To anyone who understands information theory and security and is in an infuriating argument with someone who does not (possibly involving mixed case), I sincerely apologize." This would help you :) Commented Jul 10, 2014 at 14:35
  • 3
    This TED talk has some interesting research on different password creation schemes, including the xkcd one: ted.com/talks/…
    – Leo
    Commented Jul 10, 2014 at 17:52
  • 11
    Just for the record: If your password actually was correcthorsebatterystaple it now got a lot less secure! Commented Jul 11, 2014 at 17:10
  • 7
    If you do use a password like correcthorsebatterystaple, take care that you aren't logging into a system that silently truncates it! A password like correcth is probably easier to guess than N#y;f8eR.
    – user51883
    Commented Jul 13, 2014 at 20:25

10 Answers 10


The Holy War

I think you will find that the correct way to generate passwords could start a holy war where each group thinks the other is making a very simple mathematical mistakes or missing the point. If you get 10 computer security professionals in a room and ask them how to come up with good passwords you will get 11 different answers.

The Misunderstanding

One of the many reasons there is no consistent advice about passwords is it all comes down to an issue of threat modeling. What exactly are you trying to defend against?

For example: are you trying to protect against an attacker who is specifically targeting you and knows your system for generating passwords? Or are you just one of millions of users in some leaked database? Are you defending against GPU based password cracking or just a weak web server? Are you on a host infected with malware[1]?

I think you should assume the attacker knows your exact method of generating passwords and is just targeting you.[2] The xkcd comic assumes in both examples that all the details of the generation are known.

The Math

The mathematics in the xkcd comic is correct, and it's not going to change.

For passwords I need to type and remember I use a python script that generates xkcd style passwords that are truly random. I have a dictionary of 2^11 (2048) common, easy to spell, English words. I could give the full source code and a copy of my list of words to an attacker, there are still going to be 2^44 possible passwords.

As the comic says:

1000 Guesses / Sec Plausible attack on a weak remote web service. Yes, cracking a stolen hash is faster, but it's not what the average user should worry about.

That strikes a nice balance between easy to remember and difficult to crack.

What if we tried more power?

Sure 2^44 is ok, but GPU cracking is fast, and it's only going to get faster. Hashcat could crack a weak hash[3] of that size in a number of days, not years. Also, I have hundreds of passwords to remember. Even xkcd style it gets hard after a few.

This is where password managers come in, I like KeePass but there are many others that are basically the same. Then you can generate just one longer xkcd pass-phrase that you can memorize (say 10 words). Then you create a unique 128-bit truly random password for each account (hex or base 64 are good). 128-bits is going to be strong enough for a long time. If you want to be paranoid go larger, it's no extra work to generate 256-bit of hex passwords.

[1] This is where the memory thing comes in, if you're on a compromised host you have lost. It doesn't matter if you type it or use a program like KeePass to copy and paste it if an attacker can key-log / read memory.

[2] Rather than the weaker (but more likely) assumption that the attacker has just torrented a dictionary called "Top Passw0rdz 4realz 111!".

[3] Sure we should all be using PBKDF2, etc... but lots of sites are still on SHA1. (and they are the good ones)

  • 13
    @Dick99999 modern GPUs can have 6 GB of memory on a single card (although it would take 2 slots) and can easily store a dictionary of a few thousand words.
    – Nzall
    Commented Jul 10, 2014 at 9:07
  • 12
    @NateKerkhofs This is scary and amazing in same time. My first (programmable) machine had 1mhz and 64kb ram and you talk about 6GB video memory...
    – PTwr
    Commented Jul 10, 2014 at 13:11
  • 4
    "128-bit truly random password..." Truly random? Isn't it still pseudorandom?
    – DLeh
    Commented Jul 10, 2014 at 15:19
  • 4
    This should be the accepted answer if for no other reason than the Holy War part. Commented Jul 10, 2014 at 18:27
  • 5
    @Doorknob Once you choose meaningfull combinations most of the entropy dissapears. I won't try to estimate how many sentences you could pick, but this is probably closer to one in a billion than to one in 2^44. Commented Jul 11, 2014 at 17:17

Schneier writes this:

This is why the oft-cited XKCD scheme for generating passwords -- string together individual words like "correcthorsebatterystaple" -- is no longer good advice. The password crackers are on to this trick.

but the key to understanding what he is really after is a little further in his essay:

There's still one scheme that works. Back in 2008, I described the "Schneier scheme"

so that's it. Ole' Bruce wants to assert that his scheme is the One and Only, the best, the winner, the ultimate scheme. Therefore, he needs to say disparaging things about the "competitors", regardless of whether such assertions are scientifically sound or not.

In this case, it has always been assumed that the password generation method is known to the attacker. That's the whole point of entropy computations; see the analysis. That attackers are "on to this trick" changes nothing at all (when an attacker knows the password generation method, the entropy computation describes exactly the password strength; when the attacker is incompetent and does not know the password generation method, the password strength is only higher, by an amount which is nigh impossible to quantify).

The quip about "passwords in memory" is just more incoherent ramblings. Passwords necessarily go to RAM at some point, whether you type them or copy-paste them from a password safe, or anything similar.

My guess is that Bruce was drunk.

Update Schneier was specifically asked to comment about his passphrase condemnation in a Reddit AMA (via archive.org, original link) that took place August 2, 2016. He continued to advocate for his password creation system as a superior alternative to random word passphrases. Schneier did say his scheme "gives you more entropy per memorizable character than other methods" which is true when compared to characters making up words. But this is also irrelevant when a system relies on memorizing words rather than characters, and you're allowed to combine enough words to generate adequate 'entropy' for your passphrase as a whole.

  • 33
    Yeah, I thought his comments were an odd departure from his typical good advice. His recommended scheme probably isn't bad, but hasn't been subjected to much actual testing. The passphrase approach is fairly easy to test in comparison, and you'd think that would appeal to the cryptographer in him. Maybe he just skimmed over the news about cracking natural language passphrases and didn't see a distinction between those and random word passphrases.
    – PwdRsch
    Commented Jul 10, 2014 at 16:30
  • 3
    Your argument about him needing to denigrate the competition fails, since immediately after describing his scheme, he says "Even better is to use random unmemorable alphanumeric passwords (with symbols, if the site will allow them), and a password manager like Password Safe to create and store them".
    – wfaulk
    Commented Jul 16, 2014 at 15:16
  • 19
    @wfaulk Password Safe is Bruce Schneier's creation, so his argument about the competition still stands. Your fail statement fails ;-)
    – AviD
    Commented Jul 17, 2014 at 12:08
  • 4
    @AviD: I totally did not know that. 😳
    – wfaulk
    Commented Jul 21, 2014 at 23:43
  • 12
    What you're missing, and apparently Schneier as well, is that there is no "trick" to "catch on to". The security of Diceware already assumes the attacker knows about the scheme, in fact it assumes the dictionary itself is known. It doesn't matter if the attacker has your exact dictionary and number of words: there are simply too many combinations to go through to make any sort of successful attack before the sun explodes.
    – Ben
    Commented Jun 13, 2017 at 14:32

[Disclosure: I work for AgileBits, the makers of 1Password]

One of the reasons why I advocated for an XKCD-like scheme (before it got called that) in Toward Better Master Passwords back in 2011 is precisely because its strength does not rely on the attacker knowing what scheme you used. If I may quote myself

The great thing about Diceware is that we know exactly how secure it is even assuming that the attacker knows the system used. The security comes from the genuine randomness of rolling the dice. Using four or five words should be sufficient against the plausible attacks over the next few years given observed speed of password crackers [against 1Password Master Password]

What the XKCD comic does not effectively communicate is that the selection of words must be (uniformly) random. If you ask humans to pick words at random, you get a heavy bias for concrete nouns. Such biases can and will be exploited.

How much strength you want

In a perfect world we would want to strength of our password to be as strong as the keys we are protecting with it. Say 128 bits. But despite these techniques, humans aren't going to achieve that. So let's look realistically at attacks and what we can have our puny little brains do.

With the original Diceware word list of 7776 entries, you get approximately 12.9 bits per word that you use. So if you want at least 64 bits for your password, then five words will do it.

Guessing passwords is slower than guessing keys

In this section I arrive at a very rough back of the envelope estimate that for a constant amount of dollars it is 2^13 times slower to test a password than it is to test an AES key.

Note that testing a password is a lot slower than testing a key. If the right sorts of password hashing schemes are used, it is possible to keep most attackers down to under 100000 guesses per second. So while we might never want to use 50 bit keys, using 50 bit passwords might still make sense.

If we aren't going to limit ourselves to rolling dice as in Arnold Reinhold's original Diceware scheme from 1995, then we can use a longer list of words. The Strong Password Generator in 1Password for Windows uses a list of 17679 English words between 4 and 8 letters inclusive (stripped of taboo words and words that involve an apostrophe or hyphens). This gives about 14 bits per word. So four of these gives you 56 bits, five gives you 70.

Again, you do need to pay attention to cracking speeds. Deep Crack back in 1997 was able to run 92 billion DES tests per second. Assuming that a high end specialized PC can perform one million guesses per second against a reasonably well hashed password could do 1 million guesses per second, then passwords today are about 16 bits harder to crack than DES keys were in 1997.

So let's look at this Stack Exchange estimate for a dual core 3.8GHz processor: 670 million keys per second. If we were to assume $5000 in hardware, we can easily exceed 10 billion keys per second. So at a similar hardware cost, key cracking is still more than 2^13 times faster than password cracking.

Revised password strength goals

Working on my estimate that it is 2^13 times more expensive to test a well-hashed password than it is to test an AES key, we should consider a reasonably well hashed password as being 13 bits stronger than its actual entropy with respect to cracking. If we want to achieve 90 bits of "effective strength" then 77 bits of password strength should do it. That is achieved with a six word Diceware password (77.5-bits) from the original list and 84.6 bits with six words drawn from a list of 17679 words.

I don't expect most people to use passwords that long. I expect people will use things that are 4 or 5 words long. but if you are genuinely worried about the NSA going after your passwords, then six words should be sufficient assuming that you use a decent password hashing scheme.

Very rough estimates only

I didn't spend a lot of time researching costs and benchmarks. There are lots of things in my estimates to quibble with. I attempted to be conservative (pessimistic about the scheme I'm advocating). I've been vague about "well-hashed passwords" as well. Again, I'm being very conservative with respect to the password hashing in 1Password. (For our new data format, attackers have been kept to under 20,000 guesses per second and for our older data format they've reached 300,000 guesses per second for multi-GPU machines. In my estimates here, I've picked 1 million guesses per second for a "reasonably well-hashed password".)

A few more historical notes

The overall idea for "XKCD-like" passwords goes at least as far back as the S/Key one time passwords from the early 1980s. These used a list of 2048 one through four letter words. A six word S/Key password got you 66 bits. I don't know if this idea of using randomly selected words from a list for a passphrase predates S/Key.

In 1995, Arnold Reinhold proposed Diceware. I don't know whether he was aware of S/Key at the time. Diceware was proposed in the context of developing pass phrases for PGP. It was also before most computers had cryptographically appropriate random number generators. So it actually involves rolling dice. (Although I trust the CSPRNGs on the machines that I use, I still enjoy "rolling up a new password").

In June 2011, I revived interest in Diceware in Toward Better Master Passwords with some additional modification. This resulted in my 15 minutes of fame. After the XKCD comic came out, I produced a geek edition that walked through some of the math.

In July 2011, Randall Monroe had picked up on Diceware-like schemes and published his now famous comic. As I am not the inventor of the idea, I don't at all mind being upstaged by the comic. Indeed, as I said in my follow-up article

What took me nearly 2000 words to say in non-technical terms, Randall Monroe was able to sum up in a comic. This just shows the power of math ...

But there is one thing about how the comic has been interpreted that does worry me. It is clear to me and people who already understood the scheme that the words must be chosen through a reliably uniform random process. Picking words "at random" out of your head is not a reliably uniform process.

  • 5
    Great that you mention Diceware in a historic perspective and at the same time acknowledge the great marketing job XKCD did for passphrases. About your modified scheme, is anywhere explained why 3 or 2 letter words are not included in those word lists? see blog.agilebits.com/2013/04/16/… . Is it because the words like 'off' and 'line' could also be attacked by 1 word offline? See my comments on the post of Raestloz. The original Diceware list contains many 1, 2 and 3 letter words.
    – Dick99999
    Commented Jul 11, 2014 at 9:09
  • 2
    Excellent question! My (possibly erroneous) thinking at the time was that I also wanted passphrases to be a minimum length. I wanted to make sure that if someone used a three word passphrase, it would exceed a minimum of 12 characters in length. I note that S/Key also allows 1, 2, and 3 letter words. Commented Jul 11, 2014 at 19:36
  • 2
    I quickly checked the word lists my SimThrow passphrase generator and tester uses. The original Diceware list has at least 1400 of these collisions like 'any' 'how' and 'anyhow'. That may degrade a 4 word sentence to 3 words, if no separator is used. It's a high collision number because that list includes all letters and 2 letter combinations. So it seems you made the right choice to not include 2 letter words. Diceware advises a minimum sentence length of 17. My generator estimates both the word and character based recovery times, to cope with sites that allow short passwords (20) only.
    – Dick99999
    Commented Jul 12, 2014 at 7:07
  • 2
    I also checked the following wordlists. S/Key: > 93 collisions, expanded-dicelists US: > 190 and my Netherlands list: > 750. A way to handle this is to recommend including a separator character between the words of a phrase.
    – Dick99999
    Commented Jul 14, 2014 at 10:44
  • Beware, rolling dice is not perfectly random. forbes.com/sites/davidewalt/2012/09/06/… And insidescience.org/blog/2012/09/12/…
    – wberry
    Commented Jul 23, 2014 at 14:57

The XKCD password scheme is as good as it ever was. The security doesn't derive from it being unknown, but from it being a good way to generate memorable passwords from a large search space. If you select the words to use rather than generate them randomly, though, this advantage is lost -- humans aren't good at being random.

The bit about memory is poorly stated, but it is a concern: if password-stealing malware ever gets on your computer, it'll sweep up everything text-like from RAM and the hard drive to use in a directed attack on your accounts.

  • 30
    +1 I don't think the XKCD technique is dead - it's not 'a trick' that crackers 'are on to'. You can know the technique inside out but that doesn't make it any more crackable if it's random enough. Commented Jul 10, 2014 at 7:15
  • 10
    @PiTheNumber if you're using not enough words or a tiny dictionary, then you aren't applying the xkcd technique at all; but no, even in the xkcd comic it's explicitly clear that you are NOT losing your advantage if you tell everyone "hey, I'm using correcthorsebatterystaple style password" - the amount of veriations/entropy bits is higher than most normal passwords even if the method is known.
    – Peteris
    Commented Jul 10, 2014 at 10:06
  • 38
    Provided you don't also use XKCD's random number generator (I won't link, everyone knows it). Commented Jul 10, 2014 at 11:56
  • 8
    @PiTheNumber the concept of '11 letter truly random password' is irrelevant, as it is not a reasonable alternative to passphrases. Passphrases are alternative to memorizable passwords, and those are exactly as weak as xkcd describes. Sure, if you use a password stored in a password manager, then completely random passwords fit, but in that case it's essentially not 'your password' as in something that you would use or see, but rather an 'autogenerated random key token' similar to ssh keys.
    – Peteris
    Commented Jul 10, 2014 at 12:07
  • 8
    @PiTheNumber The words are not human-chosen, they are chosen randomly. The dictionary from which the words are chosen is itself human-chosen, but that is a different matter. There is no “most likely” — the math in the xkcd comic is correct. Commented Jul 10, 2014 at 18:10

As others have said, the attack Bruce Schneier describes is effective when the user chooses multiple words him/her-self, not using a tool. Schneier usually writes to a general public audience, which is unlikely to grasp the difference between self-chosen "random" words and program-chosen random words.

I'll add that even if you use a script or other tool to randomly choose words from a dictionary, you have to use the first sequence it gives you. If you decide, "I don't like that one," and run it again until you do like it, it is no longer a random passphrase, it is human-chosen.

Also, even if you use a script, and even if you don't damage the randomness by choosing your favorite of multiple sequences, there is still the possibility that an attacker could exploit your PRNG (pseudo-random number generator). If the attacker can learn when you created the password, and what PRNG you used, and maybe other information about your PRNG such as network traffic that was produced using your PRNG around the same time, that could reduce the effective entropy of your random passphrase.

Perhaps a bit esoteric, but if your PRNG is exploitable, the 2^44 figure will not be fully realized. (And if you assume "no one will try to exploit my PRNG", why do you care about using a truly secure passphrase?)

  • 2
    +1 Interesting angle. Exploiting the PRNG is obvious in the context of encryption keys - it's interesting that it seems to be virtually an afterthought here. I guess typical passwords are so bad that PRNGs feel secure by comparison. Presumably, if an attacker can steal a list of hashed passwords, finding the pwdChangedTime or equivalent would be trivial? Another reason to end the practice of password aging? Commented Jul 10, 2014 at 21:34
  • Quick back of the envelope. If you update the password within a minute of generating it and the only source of entropy in your PRNG is the system time, you may be looking at cutting things down as far as 2^35 for nanosecond resolution. Sound reasonable? Commented Jul 10, 2014 at 21:53
  • 1
    Suppose I reject a phrase because I don't like a word and do that 1000 times. Then I have reduced the dictionary by 1000 words. Is the choice from that reduced dictionary still random? If it still is, then a 4 word sentence from a thus reduced 7776 word Diceware dictionary still gives (7776-1000)^4 = 2.1E15/50.9 possibilities/entropy bits, down from 3.7E15/51.7 possibilities/entropy bits for the full dictionary. I am not able to judge the influence of the random generator. I use the one from www.random.org
    – Dick99999
    Commented Jul 11, 2014 at 6:49
  • 4
    @Dick99999 I don't think it's really about the number of offered choices you exclude in choosing one password. It's about the pattern of what phrases you would exclude, if presented to you. An attacker might guess that the user will prefer shorter words, words easier to type on a QWERTY keyboard, and words with no capitals or punctuation; this strategy could greatly shrink the space of passphrases to explore. Basically, it's the same issue as just guessing favorite sports teams, birthdays and kids' names.
    – wberry
    Commented Jul 11, 2014 at 15:25
  • 2
    @wberry I don't think the math works out on that. Suppose you reject 1000 passphrases before finding one you like. Then it's a reasonable estimate that you only like 1/1000 of the possible password space. Now suppose that an attacker is able to completely guess which 1/1000 of the space is your favorite - that reduces the number of possibilities from 2^44 to 2^34, which is significant but not so much that an extra word can't pad out the loss. Plus, if you limit your rejections even this is not necessary. Commented Jul 16, 2014 at 3:03

It depends. One thing you need to understand is that this is not security-by-obscurity: the entropy values used in the comic assume that the attacker already knows you're using this method. If the attacker doesn't know how you're generating the passphrase, then the entropy goes up massively.

The trick to the XKCD method is that you need to actually use a random number generator and a good word list: never pick the words yourself, not even "randomly" (in quotes because humans are actually really bad at picking things randomly, which is why you shouldn't do it). Diceware has tools to help you do this, and even takes the random element out of the computer's reach by using ordinary dice.

Against a broad-based attack -the sort of thing where an attacker got a list of passwords from a Website and doesn't know anything about whose passwords are in the list- this is as strong as it ever was. Just as you say, its strength comes from the power of exponents (and a good word list).

Schneier's attack can work, but only in an entirely different context. His attack assumes that you are being specifically targeted, by an attacker who already knows a great deal about you. This might not seem especially worrisome at first, because the stereotypical determined attacker is an intelligence agent behind a screen, and most of us don't have to worry so much about those: there are only so many of them, and each one can only afford to care about so many people. But it's actually more of a problem than it might first seem, thanks to the advent of sophisticated malware. A malware installation can afford to care about you even though the attacker does not, and so you still wind up facing an extremely determined attacker. Even more determined than a human could be, in fact, though far less creative.

Malware that compiles information on you will give words that seem important to you very high priority in the word list. It does this because most people pick the "random" words themselves, but in so doing, they actually bias quite strongly toward the words that are most important to them: it may still "feel" random, but some words are much more likely to come up than others. For that reason, giving these words high priority often results in relatively quick hits, and this is the "trick" that Schneier is talking about.

However, you can still thwart Schneier's attack by using real randomness. The catch is that this requires discipline: all decisions about what words to use in your passphrase (aside from choosing a good word list) must be taken completely out of your hands. This is where things like Diceware can help you.

  • 10
    @Gilles: The reason that the entropy goes down if the attacker knows the method is that it changes the whole structure of the password. If you don't know the method, then "correct horse battery staple" looks like 216 symbols from a 2-symbol alphabet: in other words, 216 bits. If you know that it's four English words (and know XKCD's wordlist), then it looks like 4 symbols from a 2048-symbol alphabet. 2048^4 is big, but it's smaller than 2^216, which is how many bytes of entropy a truly random bit string of that length would have. But XKCD's claim already accounts for that: 2048^4 = 2^44. Commented Jul 10, 2014 at 18:27
  • 2
    Assuming that attackers believe that passwords are bit strings that follow a uniform distribution is a totally unrealistic model of attackers. Knowing the method only accounts for a handful of bits of entropy. Commented Jul 10, 2014 at 18:58
  • 2
    Entropy is not defined on strings, but on methods to generate strings. XKCD describes a method to generate strings, which has 44 bits of entropy. The domain of that method contains strings that are 27 characters long, as well as strings of other length — but the length of the strings isn't interesting from a security perspective, only from a usability perspective. Commented Jul 10, 2014 at 19:28
  • 2
    Why would you know the length of the password, but not the fact that English words are more likely than average to appear in passwords? Again, your attacker model is completely unrealistic. Attackers don't go “hey, I'll generate all possible 27-letter passwords”. They go more like “hey, I'll generate all possible passwords in decreasing order of likelihood”. Commented Jul 10, 2014 at 19:51
  • 6
    @Giles Actually both the string and method are relevant. You claim The Spooniest's opening paragraph is wrong, while making an argument that seems to restate it. If you don't know how the password is generated the entropy does go up greatly - ~166 bits for 27 characters (upper, lower, digit, punctuation). What you are saying is that attackers can use knowledge of how passwords are generated to reduce this. Seems like you are arguing the same thing from opposite ends. Also, not knowing the length increases the entropy. Commented Jul 10, 2014 at 20:06

The strength math is quite simple if word choice is at random: (number of words in dictionary)^(number of word in the sentence), assuming the attacker knows the number of in the dictionary. So a 5 word phrase using a known (by the attacker!) 7776 word Diceware dictionary: has 7776^5=2.8E19 or 64 bits of entropy.

There is one item that is not mentioned in the scheme: by adding just 1 (random) character at a random place in the whole phrase, the strength is up by about 10 bits, see Diceware, Optional stuff.

The above math also does not account for separator symbol between the words. That can add another 5 bits.

  • 18
    The point (or at least one of them) of the XKCD comic is that adding one random character at a random place increases the difficulty of memorizing the password more than it increases the difficulty of cracking it.
    – Mark
    Commented Jul 10, 2014 at 7:41
  • True for memorizing in general, not true for a master password of a vault, I think. I see 'easy to type' as the main advantage. I encounter more and more situations where password managers cannot fill in the password (apps, WifI guest network) and I have to type them.
    – Dick99999
    Commented Jul 10, 2014 at 7:49
  • 2
    @Mark - the extra random (or just non-dictionary) characters could be the same across all your passwords meaning you won't forget it. You'll earn the extra bits of entropy at least until several other of your passwords are compromised at which point the password is still xkcd-strength... Commented Jul 10, 2014 at 11:28
  • @imsotiredicantsleep - That is a very interesting suggestion. Always looked for a solution to make this strengthening technique more easy to use. It could be called security by obscurity because the attacker can benefit from the knowledge about the random character and the position. A slight trade off, I think between ease of use and secure.
    – Dick99999
    Commented Jul 10, 2014 at 18:22
  • @Dick99999 absolutely, it's a trade off. But until the constant component is compromised it will defeat a naïve dictionary attack, and significantly slow a more sophisticated one. I don't agree that it's security by obscurity though, as I can tell you that I am using the technique without losing the entropy that the possible values give me. The main weakness is that once the constant part is known you have sacrificed password real-estate that could have been randomised. Commented Jul 10, 2014 at 18:42

I'd also like to add a yes answer also, but for other reasons. It's not a good advice [in general] because of length constraints:

  • Sites like Skype, ING, eBay, and in my country Binckbank ans KPN limit passwords to 20 characters. (That bank limit is 15, but it used 2 factor authorization)
  • With an average length of 4.5 characters/word for a short 3000-8000 word dictionary, that allows for using 3-4 word phrases only.
  • When using large dictionaries the average may be 6-7: 3 words only
  • If the site insists on using a symbol and a number in the password, only 18 characters are available for the phrase.

Those lengths only protect against online attacks. For Off-line attacks is depends on the key derivation and hash function, iteration counts and cracking hardware used by the site of app, whether a 3-4 word phrase offers sufficient protection.

  • 11
    Sites that limit the length of passwords are often a great indicator that their password storage system is very insecure. Run away. All in all, password strength requirements tend to be more detriminal than helpful, IMO (both to security and memorability).
    – Luaan
    Commented Jul 10, 2014 at 13:33
  • 2
    Add Suntrust to the list of passwords limited to 15 characters. I wonder what is up with that industry.. Commented Jul 10, 2014 at 14:27
  • 11
    On the flip side, it's significantly easier to type 'correcthorsebatterystaple' on a smartphone than keep toggling between lowercase, uppercase, numbers and punctuation.
    – Dragon
    Commented Jul 11, 2014 at 10:31
  • 1
    Low password limits don't just mean insecure password storage methods--they mean passwords are being stored in plaintext or are encrypted (not hashed). @Ángel My passwords for all Microsoft-related accounts are longer than that, so I call BS. Ages ago, before NTLM, Windows passwords were limited to 16 characters, iirc. That predates XP and is hardly relevant.
    – Zenexer
    Commented Jul 14, 2014 at 5:29
  • 2
    @Zenexer Regarding the Microsoft accounts: Microsoft online accounts (live.com, Office 365, etc.) are limited to 16 characters (letters, numbers and some symbols are allowed). Commented Jul 15, 2014 at 14:29

No, I don't think so.

The actual advice in that xkcd comic are to use mnemonics that are easy for you to remember and generate password as long as you can remember them. Those are basic password advice anywhere, and will always stand true (even the quoted Schneier's method uses these two basic facts). Indeed, the comic makes use of common English words, but your implementation doesn't have to be, nor did the comic implies that you should.

Of course, the most secure passwords are totally random strings like how an MD5 string looks, and you probably can use a password manager to store all those passwords, but then what password are you going to use for that manager? ¯\ (ツ)

  • 2
    "Of course, the most secure passwords are totally random strings" NO, see for a comparison en.wikipedia.org/wiki/Password_strength#Random_passwords
    – Dick99999
    Commented Jul 10, 2014 at 8:59
  • 3
    No, that's not what the xkcd advises, I suggest you read it again - and the analysis in the relevant question here (linked above).
    – AviD
    Commented Jul 10, 2014 at 10:33
  • 2
    Your signature "¯\ (ツ) /¯" is an excellent password: short, easy to remember, really hard to break, hard to detect as a password on a log.
    – dan
    Commented Jul 10, 2014 at 21:56
  • 4
    @Daniel Azuelos, ... trivial to add to a list of strings in common usage... Commented Jul 10, 2014 at 22:05
  • 3
    @Raestloz A person speaking a language that doesn't use characters that lie in the ASCII range isn't going to use an ASCII password. Do you think all those people in Asian lands use two keyboards, one for everyday typing, and one for passwords? Unlike thirty-year-old operating systems, like DOS, all modern OS's handle Unicode and other character sets/pages just fine, and any website should support them (so long as the developer doesn't encode the form using a random charset each time, or let the browser choose). Passwords are just bits that mean something to humans.
    – phyrfox
    Commented Jul 11, 2014 at 13:27

It's important to have the right context. The xkcd comic compares Tr0ub4dor&3 at an assumed 28 bit entropy (though I calculate it as 34.6) to correcthorsebatterystaple and its assumed 44 bits of entropy (a four word diceware code is 51.7 bits … but one of those words isn't diceware. Using a simple 100k-word spelling dictionary, I calculate it to be 66.4 bits).

First, let's make this easier to understand. There are 94 printable characters. A one character password has log₂(94) = 6.55 bits of entropy. Two characters have log₂(94²) = 13.10 bits of entropy. You can divide the final entropy of a password scheme by 6.55 in order to determine the equivalent complexity of a purely random password as measured in characters.


  • 28 bits of entropy ≈ 4.3 character password (very bad!)
  • 44 bits of entropy ≈ 6.7 character password (also bad)
  • 66.4 bits of entropy ≈ 10.1 character password (okay for 2016)

Trusting xkcd's numbers, you can see why Schneier was concerned. This seems a bit overblown, as most attackers will still give up after ten or so characters [citation needed] —it should take a few years for a big cluster to break a 10-char MD5 hashed password— though obviously if a good attacker knows your scheme, absolute character length isn't an issue.

The total complexity of the scheme is most important. You must assume the worst case (that the attacker knows your exact scheme). It's a great idea to additionally ensure your password is 11+ characters (when permitted), but that's a secondary priority (and it comes for free with pass phrases).


Create pass phrases with four words plus a passcode

Here is my passpharse creation advice (with entropy estimates):

  • Make a nonsensical "sentence" of 4+ words of 4+ characters each (100,000⁴)
  • None of these words can be connected to you –or each other– in any way
  • Use case, spaces, and at least two symbols or punctuation marks (32²)
  • At least one word should fail spell check (e.g. leetspeak, foreign words, 64 each)
  • Include at least one other "error" (spelling/grammar/syntax, entropy unknown)
  • Between two words, add a traditional "random" 7+ char passcode (92⁷)

This should be at least log₂(100000⁴ × 32 × 3 × 64 × 92⁵) = 112 bits of entropy (which is very strong, ≈17 chars). I skipped capitalization (I assume only the first char is uppercase) and one symbol (I assume it ends in ., !, or ?, so the second symbol has a complexity of 3) and I also assumed that "random" isn't quite random and calculated the code as a five character equivalent (strict adherence to the above formula would give you 128+ bits of entropy at ≈20 chars).


That final point is worth repeating:

Humans are very bad at generating randomness

Very very few human-generated "random" character passcodes even approach true randomness. There will be patterns in the code related to the person's keyboard, favorite numbers, and/or an assumption that a certain obscure word is unguessable.

I designed this scheme to be robust against people's inherent lack of randomness; assuming a limited vocabulary (say the 2600 words in Basic English), use of related words (penalized by counting only three words), and a passcode limited to just the entropy of six alphanumerics, log₂(2600³ × 62⁶) itself is still strong at 70 bits (≈10.6 characters).

Don't let this water down your passphrase! This section is present to demonstrate that this scheme has some resistance to the limited entropy of human choices, not to encourage poor choices.

The only real trouble comes from people who take quotes or lyrics as their four words. These pass phrases are trivially defeated if the quote or lyric can be guessed (say by looking at your Facebook likes) or would otherwise have an entropy of around 6 random characters at a crack time of 30 seconds (MD5) to 17 days (PBKDF2).


You can use my entropy table to calculate the entropy of your passphrase scheme.

(Don't concern yourself with the fact that passwords briefly live in memory unless you're a developer)

  • 3
    It should also be noted that non-ASCII characters are like silver bullets, defeating most attacks automatically. A password of ••••••••• (nine bullet characters) is embarrassingly secure (and looks the same masked as unmasked!) due to length and obscurity, though it'd be a horrible idea to actually depend on just this fact. Put a non-ASCII character in your passcode+4word and your complexity skyrockets (to calculate, use its unicode value), though perhaps at the expense of portability (what if you're using a friend's smartphone?)
    – Adam Katz
    Commented Mar 6, 2016 at 2:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .