4 ms·

I just looked at some of the hashcat benchmarks and they are clocking MD5 on one of their test machines at 115840 Mh/s. (2^50)/(115840*10^6) = 9719.43 seconds,

by mrmcd 11y ago

I just looked at some of the hashcat benchmarks and they are clocking MD5 on one of their test machines at 115840 Mh/s. (2^50)/(115840*10^6) = 9719.43 seconds, or about 2-3 hours to break one correct horse style password. I think the point is that 50 bits of entropy is not enough when you consider the speed of GPU hashing. Obviously you shouldn't use MD5 for hashing passwords, but since you often have no control over what algo a site uses (or even information about which one they did pick), assuming they will do something common and bad like unsalted MD5 isn't a bad starting point for this kind of analysis.

orblivion 11y ago
Maybe so, but then that doesn't say much about the usual alternative which has even less entropy. EDIT: Actually I was going by xkcx's claims, which start with a dictionary word and adda random tweaks to it. I don't know off hand how long a random password would have to be to match 50 bits. But ultimately, that is the question; is this method at least as good as the alternative.
- mrmcd 11y ago
  Assuming 80 possible characters (A-Z,a-z,0-9 + 18 punctuation symbols), log2(80^8) ~= 50. So a correct horse password would be about the same as a random 8 character alpha-numeric entropy wise. The XKCD argument is that correct hose style is way easier to remember. It's possible Schneier thought Munroe was arguing that a correct horse was as much entropy as a 20 character random password, even though he isn't. This is the first I've heard of this argument though so I'm not even sure how much of a controversy it is.
creshal 11y ago
IMO, there are two kinds of passwords relevant nowadays: • Password used to encrypt your password database, whichever it is • Everything else Since the idea of a password database is that you can give each website unique passwords without having to memorize it, you can go full ASCII printable range 20 digits for site passwords. Those will not be brute forced any time soon – at 128 bit entropy –, and the damage of having them leaked will be minimal. Your password database, on the other hand, should use a painfully slow algorithm for its PBKDF. If that's not using at least scrypt, you indeed have a problem. But assuming a good password database design, 50 bits shouldn't be too bad.

by mrmcd 11y ago

orblivion 11y ago

Maybe so, but then that doesn't say much about the usual alternative which has even less entropy. EDIT: Actually I was going by xkcx's claims, which start with a dictionary word and adda random tweaks to it. I don't know off hand how long a random password would have to be to match 50 bits. But ultimately, that is the question; is this method at least as good as the alternative.

mrmcd 11y ago
Assuming 80 possible characters (A-Z,a-z,0-9 + 18 punctuation symbols), log2(80^8) ~= 50. So a correct horse password would be about the same as a random 8 character alpha-numeric entropy wise. The XKCD argument is that correct hose style is way easier to remember. It's possible Schneier thought Munroe was arguing that a correct horse was as much entropy as a 20 character random password, even though he isn't. This is the first I've heard of this argument though so I'm not even sure how much of a controversy it is.

creshal 11y ago

IMO, there are two kinds of passwords relevant nowadays: • Password used to encrypt your password database, whichever it is • Everything else Since the idea of a password database is that you can give each website unique passwords without having to memorize it, you can go full ASCII printable range 20 digits for site passwords. Those will not be brute forced any time soon – at 128 bit entropy –, and the damage of having them leaked will be minimal. Your password database, on the other hand, should use a painfully slow algorithm for its PBKDF. If that's not using at least scrypt, you indeed have a problem. But assuming a good password database design, 50 bits shouldn't be too bad.