Does my account lockout policy makes sense?

Question

I have a web-based application where users can log on with username and password.

I just implemented a new account lockout feature and was wondering whether it makes sense or I totally screwed it up.

The first 3 invalid login attempts just show my standard:

Incorrect user name or password

but I store each failed attempt. For any further attempt, I lockout the account for more and more seconds and I show this to the user:

The logon failed because your account is blocked due to a previous unsuccessful attempt. 
Please wait a 18 seconds and try again.

If the failed logon count is greater 10, I lockout the account for 120 seconds, that is the max wait time.

If the proper user finally remembers the correct password, she has to wait 2 minutes, that's not too bad.

But a hacker can only try a new password every 2 minutes, which soon becomes tiresome.

After a successful logon my failure-count is reset to zero.

All the numbers here are configurable.

Problems:

• After a few attempts, I disclose that a username is valid, by displaying a different message, but I could turn that off as well and always just display the standard message.
• If the real user tries to log on while someone else is trying to break into her account, she wont be able to log in, so this is a denial of service. But two minutes after the attacker gives up, she can log in without having to call the help-desk.

Answer 1

I agree with you on the flaws, but it appears to be along the right lines.

After a few attempts, I disclose that a username is valid, by displaying a different message, but I could turn that off as well and always just display the standard message.

Yes, you should execute the same behaviour for invalid usernames too. Your site should simulate the lockout policy for these users. This will help protect against Username Enumeration.

If the real user tries to log on while someone else is trying to break into her account, she wont be able to log in, so this is a denial of service. But two minutes after the attacker gives up, she can log in without having to call the help-desk.

You're correct in this is a DOS attack against the user. Maybe you should simply rate limit attempts after X failed attempts. An artificial delay of 5 seconds would stop brute force but it would allow a legitimate user to log on. The attempts should be measured by username and IP address (separately) and the throttle should be across threads to prevent an attacker submitting requests in parallel. Again, the same logic should apply to invalid usernames too.

Answer 2

An account lockout policy makes sense since it can increase the complexity of breaking into an account in that it takes more time to brute force the account. I would suggest not outputting that the usename is valid. If the login attempt fails.. it fails ... Outputting the message about a correct user name could be useful to an attacker. The denial if service to a legitimate user is unfortunate but if the user calls the help desk it could be useful to help alert administrators to an attempt to break into an account. To me this sounds reasonable but not sure what your requirements are. In general I think lockout policies are a good idea ,but finding a policy that doesn't degrade the usability of your application is the hardest part seems like the hardest part. Hope that helps some though.

Answer 3

Failed login attempts should be counted server-side by username and IP address. If an attacker would try to bruteforce Bob, then changing the IP address shouldn't help him. Also, if the attacker would also try to bruteforce Alice too, then he couldn't, because his IP address was already added into the blacklist, while trying to hack into Bob earlier. Bob will have his account blocked, so you should e-mail him an unlock code. I'd go for 5 failed login attempts then BAN. No timeout, no hassle.