Passwords: Using 3 Random Words Is a Really Bad Idea (2017)

Imagine you got database with 100k passwords to crack. You want to crack as much passwords as possible in shortest time. You don't have time to go full brute force, and also you don't even know what was the length of password.

So first you get all dumb single passwords from dictionary (love, hate, fuck, password), if you have cracking rig or some beefed up server you will go through 100k passwords and all single words, starting with ones commonly used very quickly (sorry, but math I leave for others). Even though hash algorithm works on characters you just make hashes from dictionary words and compare to hash. You can go even further and have list of stupid words already hashed, so now you just need to compare prepared hashes (google rainbow tables), nice optimization. Then you can have improved dictionary with l33t sp33k.

Let's say you get 10% of passwords this way form 100k.

Now you see other people have stronger passwords, so still instead of going random generate combinations of 2 words and run through database, then you can go with combinations of 3 words. This will let's say get you another 20% of passwords.

There are many other optimizations you can come up with. Passwords that you did not cracked you just leave, you don't have incentives to run 12 character full brute force combinations. You have to get passwords as soon as you have them and start credential stuffing everywhere to get as much as you can. It is not some fun and games to crack your school mate password to post "I am stupid" on his wall.

So they brute force an account (a not insignificant effort and the attacker now sees your password of "fuzzykittytoes". What are they going to do with that information?

Target a bank with it? They can't bruteforce a 14 character password for the bank over the internet. What trivial method would you use to get into your bank account, if you didn't reuse that password?

Use a master passphrase instead of a password. Make it quite long, and personal, so that you won't forget it easily. The longer you make it, the more "obvious" (to yourself) can you make it sound, without compromising its security. Something like "It was a sunny afternoon the day I met my lovely puppy Rocket". Just use your own words, and the chances of anyone guessing it will be lower than those of brute forcing it.

If you want to also have a shorter password for daily use, save it in a separate database protected with that long passphrase.

Depends on the attacker, but it's probably accounted for at least partially. In some passwords where I don't care much about security I'll use this technique and some personal, site-specific mnemonic - if their logo reminded me of a gerbil, I might start with the name of a pet gerbil I once had and obfuscate it with character replacement or keyboard proximity replacement (same characters, one row up or down). These passwords are always unique to the site, which doesn't get any financial info.

When I need a secure password that's easy to remember I'll obfuscate the initials of a memorable passphrase from a joke, poem, song or book. My password manager is offline (remember the LastPass hack?) so I need to read from it once and type it in.

Update: I remembered this old article that describes some of the techniques that have been used to crack passwords, including 133t-character replacement: https://arstechnica.com/information-technology/2013/05/how-c...

Oops, that was my misunderstanding in the first paragraph :)

Maybe a clearer example w.r.t. the base^exponent value would be another highly structured class of long passwords, instead of short passwords. For example, those that are just a 2-character sequence repeated 20 times (e.g. abab...ab). You can still say that it'll take maybe up to 26^40 tries for an attacker to guess this, but that number should be more obviously too charitable, since less entropic classes of passwords are more likely to be guessed first.

More generally, this kind of counting analysis depends on your choice of attacker, and it's plausible for attackers to be more sophisticated than just trying all the strings in lexicographical order. A more concrete but still practical attack sketch adapted to the frequency of password schemes today could be: guess dictionary word combinations first, starting with common/short words/phrase lengths, then repeat with small perturbations, then more perturbations, and so on until you search all the remaining strings.

Then, the number of tries for such an attacker to find a 3-word passphrase with a few changes would be much closer to (some small constant) * (# dictionary words)^3 than (# characters)^(string length). Of course, you can still say that such an attacker would take at most (# characters)^(string length) tries to get it, but such an upper bound isn't as useful when the password is much more structured and easy to guess with a slightly more sophisticated attacker.

(Yet another way to put it: one shouldn't expect a password that's 'slightly out of reach' to be significantly more secure than a password that follows a scheme exactly - a more sophisticated attacker would test neighbouring passwords as it brute-forces the combinations in the scheme)