Choosing Strong Passwords?

“Mozilla Firefox” on Facebook just did a post suggesting that people use this method to choose strong passwords. That’s a video Mozilla produced a little while ago, which suggests starting with the “take the first letter of a phrase you know” technique and adding a few more tweaks to it.

Now, no disrespect to Richard Milewski, who did that video, but I think that XKCD’s analysis of this kind of technique is very compelling. The passwords produced by the method we are promoting are not very memorable, because the algorithm has too many variables. Perhaps we should switch to suggesting the XKCD method? My ISP, Andrews & Arnold, apparently switched for all new accounts on the day that cartoon was published.

12 thoughts on “Choosing Strong Passwords?

  1. s/password/passphrase/g

    If the word phrase rather than word is used people will automatically make the character string a lot longer and, possibly, include punctuation as well.

  2. This post gets me to an idea of improving the UX so that the user gets a clue how weak or strong his or her password is. The idea is based on harnessing the spell-check dictionary, beside the others. The UX would use temperature-like colorizing asterisks inside the password field. How it sounds?

  3. If BrowserID becomes more widely used, isn’t it entirely irrelevant what the password you use is?

  4. If we’d know in advance that the user password contain four dictionary words, cracking it would be easier than testing every possible combination.

    I am still thinking that we should stop using plain text passwords and start using private keys and technologies like openid to authenticate to 3rd party sites.

  5. Hi Gerv:
    Some time ago, I tried to translate the (unpublished) “How to chose strong passwords” article for SuMo. Eventually I gave up – for an evident reason: every time I laid my fingers on it, I succeeded to plant another typo in the worst possible place(s). Eventually it dawned on me that this is the perfect approach for keeping users outside instead of letting them in.

    Regards

    smo

  6. > If we’d know in advance that the user password contain four dictionary words

    The estimation of how much entropy it contains assumes that the attacker does know, in general terms, how it was constructed. The exact amount of entropy varies considerably depending on the size of your dictionary file, but even with a modest spelling dictionary (like, say, the /usr/share/dict/words file from a Debian system), four words strung together gives you a search space of about 94388121240998916240 possibilities. (No, I didn’t just make that number up. I used wc and a calculator: 98568 words of which you’re taking four with no repeats.) In contrast, a traditional mixed-case eight-character random alphanumeric jumble, which is MUCH harder to memorize, has only 2821109907456 possibilities (meaning, the four-dictionary-words one will take about 33457796 times as long to brute-force, all else being equal; that’s roughly the amount of difference between five minutes and sixty years, though of course the exact time figures depend heavily on the resources devoted to the problem). The hybrid modified-dictionary-word variant discussed in the xkcd strip is harder to pin down precisely (because you have to try to decide what constitutes a “common” substitution), but it’s clearly somewhere (relatively) near the hard-to-memorize and easy-to-brute-force end of the scale.

    It is, of course, possible to make a password both easy to memorize and easy to brute force, which is what most people do if you don’t warn them off it; the year you graduated high school is a perennial favourite, or your initials, or the name of your favorite sport or hobby, or the pet name you call your spouse.

    Obviously if you want to make it both hard to brute-force and hard to memorize all you’ve got to do is make it a really LONG random jumble: your new password is 8*z_9NuciD\e-athi9R4-\(FE:r;9Ez6nj0fPF^b>J i@a&M&p*?B>5b#Yz3Q!gs\|7ZUu#n67-h*uW wBD~soIrf?z1eg.%uFK+4QqNPDEg)2jt/T8;C&V)WP;$Qo3D4T4 UVne8IV4rJ9Y:5.OG$)-R=8soSuz=0AY.w6-XY@X 9(CTNkMiA)&$XCz/jrSqVJ&C+e*/m)i%wCC.s\/zs^G vDCEP50zlOX1g\t\9&<XXhy^TgEMjmecf<FCLph)jL;.eX$ Yl)y;x=68TIWdEr0jtMOXd!:AM6~x;@|o.Jg3=R.
    Have a nice day.

    But yeah, what we should really be thinking about is how to make them *easy to memorize* and, within that constraint, as hard as possible to brute-force. Stringing multiple dictionary words together does indeed go a long way toward this.

    The traditional wisdom that dictionary words make a password easy to brute-force is based on the assumption that all passwords are all approximately the same length. Older password systems had length limits, due to technical constraints. That was valid at the time (before regular non-scientist type people were using computers, also before I/O that could outstrip a normal person's typing speed), but it's no longer even a little bit relevant now. There's no longer any reason a password can't be six or eight words long if you want.

    Yes, I do think it would be a good idea to start calling it a "passphrase" rather than a "password". If you think a string of random words like "correct horse battery staple" is easy to memorize, try a meaningful series of words, like "Brianne's Birdwatching Society likes jays and cardinals." You can even make that case-insensitive and ignore spaces and punctuation without significantly reducing the amount of entropy. Heck, you can run a (deterministic) spelling-corrector over it first, then strip out spaces and punctuation before checking whether it matches, without significantly reducing the amount of entropy.