Why the password "this is fun" is 10 times more secure than "J4fS!2"

The danger with semantically meaningful passphrases is that they have a lot less entropy than you think they do. I still use them for everything, but it is something to be aware of. (You can get more by e.g. padding it with a number, doing the usual l33tspeak tricks, etc.)

Assume there are 7500 very commonly used english words. A three word sentence, all in lower case, would yield 421 Billion permutations. Let's say, of those 421 billion permutations, which don't tense or plural nouns about 1 in 5 are familiar english language constructs, which drops down to around 20 billion permutations. In this case, if we took all capital letters, all numbers, and 6 punctuation characters, we'd end up with ~67 unique characters, for a combined 82 billion permutations.

Furthermore, like Richard Feynman discovered in Los Alamos, you could narrow down the possibilities of combinations if you know something about a person. You could probably build profiled dictionary attacks and reduce possibilities a lot.

So, is it more secure? No, it's maybe equally secure, but it would completely depend on the attack. A combination of capital letters would probably be more secure though.

One advantage of gibberish passwords like "b923F$5mvA" is that if someone looks at your fingers while typing them, he'll have a hard time figuring them out from your keypresses, whereas if you typed "this is fun", it would be much easier.

Ditto for when someone has a visual glimpse of your password which is only a few seconds long. (e.g. someone looked at your laptop screen while you got an email with your password from an irresponsible website.)

This should be fairly obvious to anyone who's done any sort of combinatorics - you're saying that a 10 character password using symbols and lower case letters is more complex than a 6 character password using 36 more characters in the character pool. Anyone who's even glanced at password complexity research will be able to tell you that. To break down the numbers though, a 10 character password using lowercase letters and symbols (spaces) has 30155888444737843000 possible combinations. A six character password has 735091890625 combinations (around 1/4000th of the complexity, assuming a brute force approach). While the author also takes into account the possibilities of using a dictionary attack, you can't really tie a number to the search space for that. It depends on the breadth of what the program will go to. Will it check alternate spellings (color/colour)? Will it check for apostrophes? Foreign languages? Etc.

A while back I wrote a small piece of JS to demonstrate to some people the complexity growth in passwords. Some people didn't believe me that asdfasdfasdf was more complex than Fc34!j_, and this was the end result. Feel free to play with it. The source is rather simple as well:

http://files.jjcm.org/jspass

There is a huge logic gap here. He is comparing 11 characters passwords to 6 character passwords. The difference in length also will account for a significant difference in the time required with brute force.

I think what he is trying to show is that is that the lower security of using multiple common words on a password with 11 characters is still greater security than a random 6 character password, and still quite acceptable.

It's interesting. The author shows some fundamental misunderstandings and makes assumptions that are not necessarily based on real-world situations to present an idea that longer strings with more recognisable characters (e.g. passphrases) are better than shorter strings with larger keyspaces. If you pick two data points you can actually fiddle with the numbers to present either side of the argument as the truth. For example:

A full 16-bit unicode 2 character password has 65 536^2 or 4,294,967,296 permutations to work through.

A lowercase alphabetic password of 6 characters in length has 26^6 = 308,915,776 permutations.

Of course there's a tradeoff involved, and that tradeoff is what IT departments try to manage, with mixed success. It's easier for the software to determine whether or not the password contains methods of increasing the keyspace than whether or not the user has typed out a 200 character long series of 'A' characters, so that's what they use. I don't know whether or not increased length has a higher risk of collisions for some algorithms (that's tptacek territory, not mine). Over time, software products have been guided by best practice standards from organisations like COBIT that define and mandate complex passwords based on keyspace rather than length alone.

Secondly, there is a difference between an online brute force and an offline brute force. Depending on the algorithm, with the right kit (or Amazon EC2 instances) you can get billions of hashes per second to crack a password hash offline. At that point your increased length only matters if the attacker doesn't know about the complexity. The samples provided are terrible as they're all lower case with a space at most. This is the poor end of the trade-off. To brute force a SHA-1 hash of the word 'sum' on my 2 year old laptop takes less than a second.

Online brute forcing (e.g. brute forcing a web form) is generally something you're not going to do if you're looking to compromise a web account, unless it is a specifically targeted attack (e.g. the user is an admin or a specific person of interest). In these situations your brute force rate is dependent on your network throughput, the application's ability to respond to concurrent requests and any other factors that may affect it (such as any monitoring system). Your web application on a linode slice will probably choke out between 40 and a hundred attempts per second (and you'll notice it unless you're blind or have no performance reporting). If you can get past the automation detection in larger sites, like Amazon, Google, Twitter etc. you'll probably be able to go much, much higher. For this reason, web site brute forces tend to be dictionary based, or at most on dictionaries and a number.

Ultimately when choosing a password you need to consider what you're defending against. If you own the box or the app, chances are you trust the defences. If you're going to change the password every few months then maybe you will choose a weaker password. If you don't own the kit and you're not intending to use the password, then use a tool such as Keepass[1] and generate the passwords yourself. That way it doesn't matter what J Arthur Random says on the Internet, you won't need to remember the passwords at all.

[1] - http://keepass.info/

In my 25M word corpus, "this is fun" occurs 23 times. There are only 94,000 trigrams that occur more frequently.

Therefore, you should be pessimistic, and consider the password "this is fun" less safe than passwords in the shape [a-zA-Z]{3}, like "tsP", of which there are 140608.

Assume attackers know the algorithm (e.g. three common words, one 7-letter word in l33tspeak, a 6-letter string of random ascii characters) but not the parameters.

The most useful thing we can do as web developers:

- support very long passwords, so that users can use pass-phrases if they like.

- use bcrypt or the like for storage

- do not create easily cracked side channels, like a fixed set of "security questions" for forgotten passwords

"this is fun" has structure and I suspect is an easy password to guess from the pool of all three word passwords. Just like using a dictionary is better than brute force, trying common words that usually go together when guessing three word passwords is much better than trying all three word passwords. If Google were to write a "word" password cracker using their data trove, I suspect "this is fun" would go down early. Likewise putting spaces between words would be to the Google cracker like adding a number on the end of a dictionary word is to a standard cracker.

What about moving away from semantics (easy to remember words) and change to patterns on the keyboard? That's how I handle my most secure passwords. Patterns on the keyboard using all the keys and combinations of shift create passwords that are easier to remember than a random length string, and can become quite long (>8 chars).

No it's not. If I was brute forcing a password these days, I'd use the google ngram database, and "this is fun" and pretty much any other memorable phrase would fall pretty quickly.

I refuse to believe that there are no tools that can dictionary attack sentences.

hmm, perhaps I'm missing something, but shouldn't systems just not allow you to attempt to login so much and so frequently?

I guess these systems do get hammered by so many improper attempts and you'd risk blocking the actual account owner. But if a billion attempts are made from the same ip in an hour, shouldn't that be considered suspicious?

Personally, I like what Google's doing with the two-step verification. That's probably where security should be going.

Good "dictionaries" for doing on-line brute-force attacks don't just contain words, they contain likely passwords. Guidelines for choosing good passwords should point this out. For example, something like "J4fS!2" is a much much more secure password in terms of protection from on-line attacks than "letmein" or "chang3m3" or "tryandguessthis" or "password123" or "root!@#" or "b4ckm3upsc077y". All of those passwords are actual passwords taken from the list used by an SSH brute-force password cracker.

Because people aren't random when they choose words to remember (e.g. "beavisandbuthead" is also on that list), a better set of password-choosing directions would provide instructions one how to add some additional (pseudo-)randomness to passwords that are being created. The classic "pick a phrase, take the first letters + punctuation" method is one way to do that ("pap,ttfl+p" is a somewhat strong password), and it's not hard to think of other password generation schemes that also create strong passwords.

Using multiple words or even sentences as password (as described in the article) doesn't even work always, there are too many websites or application which have a password length limit.

I recommend to use a password manager, KeePass is quite good.

Good password manager should be able to easily generate a new strong and complex password every time.

Remembering only one password and getting rid of the laziness of choosing always the same password is another advantage too.

Even if a website that stored your password in clear text and someone hacks the website, you shouldn't have to worry about other applications or services you may have used with the same password.

My personal rule is to choose unique strong passwords (alphanumeric and symbols) with at least 9 chars.

Brute forcing a password with 8 chars was with my 5870 no big deal at all, but cracking a password with 9 chars is too expensive (ec2 gpu) or takes to long for the usual hacker.

If someone really brute forces my password, with gpu and a cluster support, damn, than he really deserve it.

But that's just my two cents.

He forgets one of the easiest ways of getting people's accounts:

http://xkcd.com/792/

The title is a bit misleading. The passphrase "this is fun" may be 10 time harder to brute-force than "J4fS!2", but both are hard enough that nobody would bother trying to brute force attack them. So they both are equally acceptable. I personally would rather type "J4fS!2", and here's why:

We use PGP Whole Disk Encryption at my company. The passphrase strength requirements are quite strict. It took me about two dozen attempts before I found a password that it would accept. The password was something along the lines of what the article is proposing, five short English words arranged in a sentence (about 25 characters long). This was acceptable to PGP because the software prefers longer passphrases with less entropy per character over short passphrases.

The problem is that it's quite hard to type this long passphrase in when all you can see on the screen is stars or dots. The longer a passphrase is, the higher chance there is of introducing a typo. A shorter passphrase, mixed case and with symbols, is, at least for a programmer, easier to type, especially with muscle memory.

In the case of PGP Whole Disk Encryption, they obviously realized this since you can press the tab key to enable showing the password in plaintext as you type it. I always do this because it increases the success rate of my password acceptance quite a bit.

On an unrelated note, it seems that a far bigger security risk on the Internet is the use of the same password on multiple web sites. If you use "this is cool" on ten different sites, then you are opening yourself up to serious vulnerability if one of the sites is compromised. Using a hash of a common password with the domain name provides a lot more security, but the simple implementations available today produce passwords that are short with mixed case and symbols versus long strings of words. But since the only sane way to use this approach is with a password manager, extension, or bookmarklet anyway, this doesn't seem to be a major limitation.

But having to create and remember short three to five word passphrases for dozens of web sites would be a daunting challenge!

This person is just.. confused, to put it nicely.

My password system is detailed here: http://news.ycombinator.com/item?id=2431480

It's secure, passwords are never stored, and it's not based on any false premises.

I think dictionary attacks are a far more common attack profile than looking for written down passwords. Also, pointing out common passphrases is a good way to ensure that passphrase checking makes it into later iterations of password cracking.

If site X suggests to users that they use pass phrases consisting of common words chosen at random, then "this is fun" is not very secure. A brute force attack using /usr/share/dict/words found on many Unix systems would take about the same effort as a brute force attack on an 8 character random password where characters are drawn from upper case, lower case, digits, and common punctuation.

You'd actually break most people's common words passwords using smaller word lists, say the 4096 most common words. Three words from the top 4096 chosen at random gives a password equivalent to a little under 6 characters of mixed case/digits/punctuation.

I wonder how many people will use "this is fun" as their password after reading this...

In http://qbix.com , we have implemented passphrases out of the box for all of our apps.

Try signing up there. You will find that the passphrase suggestions are quite nice. To obtain them, I took three random words, searched yahoo news for those words, and for each result, chose 3 contiguous words and presented it as a passphrase suggestion.

In the event that Yahoo is unreachable, our server generates one of 50 million unique phrases from ADJECTIVE NOUN VERB NOUN. I would say this produces greater entropy than if you left people to choose their own passphrases, even if they don't copy our passphrases exactly.

One benefit he didn't even mention: keyloggers

Someone scanning a keylogger file might not even notice "this is fun". It doesn't look like a password.

The only time someone has gotten my password was actually from a keylogger when I logged into Facebook at a hostel while traveling.

Pro tip: Another way to defeat those is using the virtual keyboard in windows to "click" your password in. I do this while traveling now. http://www.microsoft.com/enable/training/windowsxp/oskturnon...

1. Construct a complex password key with a minimum length of 8 characters, e.g -Kr/2.pq4

2. Make an algorithm based on the URL. E.g. news.ycombinator.com a) Take the last 4 characters in the URL, excluded the domain suffix: ator b) Shuffle the letters based on your algorithm: orat

3. Combine the password key and the output of your algorithm: orat-Kr/2.pq4

4. Always enjoy individual, secure and easy to remember passwords for any services.

The algorithm you use can be more complex, e.g. adding characters in between, but the basic idea should be explained.

"None can remember a password like "J4fS<2", which evidently mean that it will be written on a post-it note."

That's bullcrap. Few will remember this password, but most can if they try. My work domain password is over 8 characters in this level of complexity and it took me about 10 minutes to get used to typing it, a day to fully get it into muscle memory. If you ask me what my password is, I'd have to type it out.

I started writing a response, but then it got too big. Basically the 5 second timeout is a bad idea because its implementation is not worth the effort. http://oim.ae/gx8qMD for the reasoning.

But the other thing, use UTF8 high value characters. Or simply learn Russian and use a password from russian words.

It's a bit hard to know where to begin responding to the number of inaccuracies in the original post. So here's a complete summary: http://www.troyhunt.com/2011/04/bad-passwords-are-not-fun-an...

Another positive aspect of sentence passwords is that they are more likely to survive a keylogger attack.

Doesn't anyone use code for password?

  {login(url='google.com',user='meric',password='sun');}

The author either knows basically nearly to nothing in computer security and password bruteforcing, or knows stuffs but miserably failed to properly communicate the hypotheses used (he did communicate some of his hypotheses, but not in an appropriate way that would have rightly prevented the general public from making password choices based on this article while under radically different conditions) and caveats to take into account when interpreting his examples.

This article is misleading in the sens the results it gives are only applicable for very narrow cases, and fast reading it can give the impression that "J4fS<2" is a "secure" password and that "this is fun" is even more secure. While this can be true under those very restrictive hypotheses he used, the fact that it was not prominently warned that those hypothesis should not be blindly used for basing password choice for random online web sites or other things makes this article dangerous.

“In a sense, there is no such thing as a random number; for example, is 2 a random number?”

My undergraduate research addresses this subject:

A Comparative Study of Three Random Password Generators

http://tamale.net/pub/2007/pwdgen/pwdgen.eit2007.proceedings...

Speaking of passwords, I believe hackernews account passwords are transmitted over plain-text HTTP. Even the password reset is plain-text HTTP. Perhaps that will change soon?

When helping people construct passwords I always guide them to use an acronym from a favorite line of a song (or bible verse, or poem depending on audience) and then add a symbol and a number. So for example if you really like Led Zeppelin you might take the opening line"

"Hey Hey Mama Said The Way You Move Gonna Make You Sweat Gonna Make You Groove"

and turn it into the password hhmstwymgmysgmyg!8

or "The woods are lovely, dark and deep. But I have promises to keep"

to become: twaldadbihptk$9

Easy to remember, relatively high entropy, pretty good compromise.

This article is total crap, the author has very little in the way of security clue -- how does such nonsense make it onto HN?

This is why I like using Passpack. I can store secure passwords securely without post-its.

the author only considers common words attacks, what about common phrases attacks? with a database consisting of common sentences, (eg. from reuters) those passwords could be broken in a much shorter timeframe than claimed in the article.

TL;DR - Password fundamentals...length always beats complexity.

Not any more. Now added to all the password dictionaries.

I would not use "this is fun" ever. If it becomes at all common for people to start using 2- or 3-common words instead of smaller non-word strings, password crackers are going to start generating 2- to 4-word strings. "This" and "is" are two of the most common words in the English language. A flat dictionary approach may take prohibitively long, but a smart password cracker is going to start with the most common English words, and I just don't believe "this is fun" will survive very long.

If you use 3 uncommon words with no logical connection ("masquerade nefarious pulchritudinous") you are probably safe, but if two of your words are among the language's 100 most common, and your password is a sentence... bad idea.

A cracker faced with a 20-character password space is going to choose "this is fun" before "J4fS!2". It's only with a 6-character password space (which is pathetically small) that "J4fS!2" is likely to be hit.

Not any more.