Agreed, to stop someone brute-forcing login page is to temporary ban that user from loging in after getting password wrong 3-5 times.
It's a bit different when someone gets hold of your DB so there's no way for you to limit how many tries they get, and the hashed PW probably includes method meta-data.
Password rules/strength checkers should be clever enough to know tho that after certain length, some rules can be omitted.
And because 99.9% of people just do Capital first letter + lowercase rest of the word + easily guessable number (birthday, etc), or they use simple replacements like O is 0 or A is @, etc - it's relatively easy and quick for hackers to get around having to try every combination.
I wonder what a cost/benefit would look like for keeping salts in a separate database from the hashes. Would be helpful to know more about the specifics of large intrusions.
That's an interesting point. So even if every character is allowed in a password, an attacker could still only try combinations with lowercase characters + numbers, since most users will only use that.
So in this case, if the attacker only wants to find out a majority of passwords, those rules actually increase the password space.
Would probably be different for services that target developers though.
Agreed, to stop someone brute-forcing login page is to temporary ban that user from loging in after getting password wrong 3-5 times.
It's a bit different when someone gets hold of your DB so there's no way for you to limit how many tries they get, and the hashed PW probably includes method meta-data.
Password rules/strength checkers should be clever enough to know tho that after certain length, some rules can be omitted.
And because 99.9% of people just do Capital first letter + lowercase rest of the word + easily guessable number (birthday, etc), or they use simple replacements like O is 0 or A is @, etc - it's relatively easy and quick for hackers to get around having to try every combination.
I wonder what a cost/benefit would look like for keeping salts in a separate database from the hashes. Would be helpful to know more about the specifics of large intrusions.
I don't know that much about cryptography to really make valid argument either way.
I imagine in some ways you will have a lot more to worry about with race conditions where one DB is in sync, the other isn't.
That's an interesting point. So even if every character is allowed in a password, an attacker could still only try combinations with lowercase characters + numbers, since most users will only use that.
So in this case, if the attacker only wants to find out a majority of passwords, those rules actually increase the password space.
Would probably be different for services that target developers though.
wikihow.com/Guess-a-Password
Apparently so. I dunno. I go for length and simplicity my own accounts :)
Your users... Got few mates in hosting business, they constantly have to deal with hacked WP installs because people don't pick good passwords :|