[akatechis]

What I don't understand is the math. Author makes the claim that using 3 words changes the combinatorics from 62^12 (62 characters, in 12 positions) to 20,000^3 (20k words, in 3 positions) but a hashing algorithm doesn't work with words, it works with characters, so if the words are 4 characters each, you've still got 12 characters to fill. Since an attacker doesn't know that you've not used symbols or numbers, they can't reduce the problem space to 26^12. Right?

Have I missed something in the article that would make the connection?

EDIT: Yes, hashing works with bytes, so technically, it can be even stronger if we include charsets from other scripts in the problem space.

[eric_bullington]

Exactly. The attacker would have to try a word-based attack to benefit from the ~7 hour time-to-crack.

So I disagree with the article's advice: "Don't use words in passwords. Ever." Yes, you should use caution when using words in a password, but even if you use a password manager, a 5- or 6-word diceware password is ideal. Even better if you stick on a 4-digit numeric "salt" to your diceware passwords.

But yes, I do agree that a 3-word password is too short (~33 bits of entropy[1]). It should be at least 5 words (~55 bits). And you really need at least 6 words (~66 bits, obviously) for a master password.

1. Using EFF's user-friendly, ~1200 word list for diceware.

[ozim]

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.

[braincoke]

I haven't had the time to read the full article, however I think I might have an answer to your question. The entropy computes the strength of the algorithm used to generate passwords, not the strength of the password itself. So basically, you are getting the strength of the password if the attacker knows the algorithm.

I couldn't find a better source than this stackexchange thread : https://security.stackexchange.com/questions/167235/how-does...

Hope it helps