Re^4: Password strength calculation

[Ralesk]

I beg to differ here.

If we’re removing passwords shorter than, say, 8 (or 12) characters, or are requiring people to use capitals, digits and other characters, we might be removing things the attacker needs to check, yes… but in the end, we have not actually removed anything — we’re storing (salted) hashes, and the way cryptographic hashes (are supposed to) work, if you remove a small (and from the point of the entire possible space of input strings, negligible) part of the input space, you’re still going to end up with the same amount of possible hashes. As long as you do still have a much greater (possible) input space than the hash’s own data size, you should be fine. So it comes down to restricting utterly stupid input even at the cost of the attacker getting to know they need to eliminate a few things before trying, and using large (and slow) hashes to make an attack infeasible.

Some of your calculations — as also pointed out by others — also seem to assume that the attacker has their hands on your password DB and all they need to do is use CPU time to guess the password so they can get in afterwards, not needing to hammer on the site during this. That’s already a lost cause by that time, I’d say…

(PS: I might not have found the right spot in the thread to reply to, but oh well.)

(PPS: Also, this is not to say that passphrases are stupid, I’m all for them as opposed to weird alphanum vomits. Shame they don’t work on places like this, where you’re limited to a maximum of a few characters…)

[BrowserUk]

if you remove a small (...) part of the input space, you’re still going to end up with the same amount of possible hashes.

The number of "possible hashes" does not enter into it. It is the input space that the hacker needs to iterate, not the hash space.

That is to say, the hacker needs to find an input that when hashed, matches the hash in question. Smaller the input space, the less work he has to do.