Ideally, I'd rate limit the auth api and check against a list of commonly used passwords (and against a db of previously compromised usernames/passwords), then ditch the rules and stop worrying about brute force.
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.
Ideally, I'd rate limit the auth api and check against a list of commonly used passwords (and against a db of previously compromised usernames/passwords), then ditch the rules and stop worrying about brute force.
Great, so now you can ban any user you want my spamming requests to the password endpoint so they get temporarily banned.
Can rate limit by ip address as well as by user. Could also leverage machine learning to detect anomalies in auth rate.
IP limiter is another good option too yes.
Also, you don't have to email user that their account has been suspended for 15 minutes every single time.
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 :|