| [reply] |
You'd be right if people randomly picked a password from the entire key space (picking with a uniform distribution). But if you allow passwords with a length of 4 - 10000 characters, with no restriction on the character set, there will be people that pick a four character password, with all lowercase ASCII letters.
And attackers know that password picking cracking is more than math. Psychology plays a role as well. They will try "dictionary" attacks first, because people pick short existing words far more often than you would get by picking a random element from the total set of allowed passwords. | [reply] |
They will try "dictionary" attacks first,
Why? When it takes 17 seconds to eliminate all the 6-character alphanumeric possibilities on a single gpu, you might as well run it anyway.
Unless you know for sure that you can exclude them, in which case, why not save a few cents.
Yes, a minimum length is a good idea, but 4, 6 or 8 simply isn't enough to make the slightest difference. You aren't even vaguely affecting anything until you get to at least 12-chars these days.
The more logical approach would be to exclude all known words (in all languages). But if the attacker knows you are doing it, you've still helped rather than hindered him.
In the end, any known restrictions simply help the attacker.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
| [reply] |
| [reply] |
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…)
| [reply] |
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.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
| [reply] |