> Consider throttling invalid login attempts by IP address or subnet.
Oh hell no.
First off that is completely ineffective. Botnets are common and inexpensive. But worse still a lot of users often share a single IP (e.g. university dorms, businesses, public wifi, etc).
I agree with the first part of this article (i.e. that it is trivial to "prove" a username is valid, and that worse error responses aren't accomplishing anything). But that advice is poor.
> Check submitted passwords against a dictionary of common passwords (123456, monkey, etc) and ban that traffic extra hard.
That seems like a lot of engineering work. Plus the workload of loading up a dictionary and doing a lookup upon each login is resources that frankly could be better used on a slower hashing algorithm (to slow logins and make stored hashes stronger).
> Exponential backoff (forcing attackers to try again after 1, 2, 4, 8, 16.. seconds) is useful as well.
Just open a spreadsheet and determine how long it would take to test 1500 passwords. 1500 is a "short" dictionary of common passwords. Even a 1 minute delay after each 2 attempts (or 2 minutes after 4, or 4 minutes after 8, etc) means 12.5 hours of attempts.
I like to set the attempts really high with an equally high lockout. So no normal user will see it. Most users do a password reset after the fourth or fifth attempt, so if you set it on 8 attempts with a 4-6 minute lockout then the majority of users will never run into it.
Instead of focusing on these kind of hacks why not just:
- Set no maximum password length (250+ characters)
- Set the minimum to at least 6 or 7
- Get a password score widget (e.g. "weak" "normal" "secure"), traffic light, to encourage better behaviour
- When a password is set check it isn't in a common password dictionary (a lot of score widgets integrate this!)
- You can use Javascript to check a password dictionary as it isn't a site-security feature, and anyone who goes out of their way to bypass it only has themselves to blame.
- Agreed on 2F, Google Authenticator is trivial to integrate. The only remotely "hard" bit is generating the QR code and a lot of libraries exist for that express purpose.
- No clue how you'd integrate LastPass...
- Account Alerts are extremely useful. As are admin alerts. Too many sites get no warning when a lockout occurs, it is pathetic.
* Concurrency -- I can check a lot of passwords at once. Are there race conditions in the backoff? Can I check 20 in one second? 200? What about all 1500? (yeah, that's not subtle and alarm bells should go off).
* Alternately, one can iterate usernames against common passwords, especially if usernames are known. (and as a subset of this, if accounts are locked after n tries and usernames are iterable, that's a DOS waiting to happen)
If someone can guess the first 72 characters of your password, they probably know the rest. e.g. They have access to your password manager or you are using a common phrase.
I still wouldn't limit a user from entering in a longer password. I'd display a warning if they attempt to enter in a 73+ character password to inform them that passwords longer than 72 characters offer no additional protection.
That's a bug. Bcrypt doesn't truncate, it simply doesn't handle longer passwords. And you can pretty safely use another hash before feeding it into bcrypt.
I have to agree with the parent here... There are other ways to add security, and having an obscure error message doesn't really improve things by as much as the error message can cause real users to go down the wrong path.
Who are you "agreeing" with? Neither me nor the article is arguing for inexact error messages. We both agree that registration pages leaking that information make hiding if a username is correct a pointless exercise.
On that point me and the article are in complete agreement.
Exponential backoffs also have the problem that it makes it far easier to lock someone out of their account. Or rather, it makes it possible to lock someone out of their account for an arbitrary amount of time.
> When a password is set check it isn't in a common password dictionary
I agree with this with short passwords. But for passphrases? No. I find it rather frustrating that (ex) diceware passwords are often rejected as too insecure or flagged with a nasty warning.
> I agree with this with short passwords. But for passphrases? No. I find it rather frustrating that (ex) diceware passwords are often rejected as too insecure or flagged with a nasty warning.
I too have ran into that issue. Instead sites doing:
password.Trim().Equals(<dictionaryItem>);
They do:
password.Trim().Contains(<dictionaryItem>);
So if you do a pass-phase or full sentence they'll call your password insecure for being a common dictionary word (even if it is 20+ characters long).
That's why score systems are better overall than any one single check. All parts of the password should be considered (e.g. length, complexity, commonality, etc).
> Exponential backoffs also have the problem that it makes it far easier to lock someone out of their account. Or rather, it makes it possible to lock someone out of their account for an arbitrary amount of time.
Why not allow the unlocking of an account through email and 2fa?
An email like, "Hey, we've locked your account because we've received a ton of incorrect login attempts. To unlock your account click the big button below OR visit www.example.com/longrandomhash"
And then have the user login again (and potentially use some sort of 2fa like facebook/github/google code generator).
> Just open a spreadsheet and determine how long it would take to test 1500 passwords.
After about 58 attempts the sun would have exploded. After 1023 attempts my spreadsheet application can't cope with numbers that big.
Oh hell no.
First off that is completely ineffective. Botnets are common and inexpensive. But worse still a lot of users often share a single IP (e.g. university dorms, businesses, public wifi, etc).
I agree with the first part of this article (i.e. that it is trivial to "prove" a username is valid, and that worse error responses aren't accomplishing anything). But that advice is poor.
> Check submitted passwords against a dictionary of common passwords (123456, monkey, etc) and ban that traffic extra hard.
That seems like a lot of engineering work. Plus the workload of loading up a dictionary and doing a lookup upon each login is resources that frankly could be better used on a slower hashing algorithm (to slow logins and make stored hashes stronger).
> Exponential backoff (forcing attackers to try again after 1, 2, 4, 8, 16.. seconds) is useful as well.
Just open a spreadsheet and determine how long it would take to test 1500 passwords. 1500 is a "short" dictionary of common passwords. Even a 1 minute delay after each 2 attempts (or 2 minutes after 4, or 4 minutes after 8, etc) means 12.5 hours of attempts.
I like to set the attempts really high with an equally high lockout. So no normal user will see it. Most users do a password reset after the fourth or fifth attempt, so if you set it on 8 attempts with a 4-6 minute lockout then the majority of users will never run into it.
Instead of focusing on these kind of hacks why not just:
- Set no maximum password length (250+ characters)
- Set the minimum to at least 6 or 7
- Get a password score widget (e.g. "weak" "normal" "secure"), traffic light, to encourage better behaviour
- When a password is set check it isn't in a common password dictionary (a lot of score widgets integrate this!)
- You can use Javascript to check a password dictionary as it isn't a site-security feature, and anyone who goes out of their way to bypass it only has themselves to blame.
- Agreed on 2F, Google Authenticator is trivial to integrate. The only remotely "hard" bit is generating the QR code and a lot of libraries exist for that express purpose.
- No clue how you'd integrate LastPass...
- Account Alerts are extremely useful. As are admin alerts. Too many sites get no warning when a lockout occurs, it is pathetic.