This. I'm surprised more sites don't utilize a lockout. Even with a 10 or 50 attempt lockout (for a website not PIN) is still better than giving an attacker unlimited attempts.
The problem that I've seen with lockouts is that they become a route for denial of service attacks.
If lists of usernames/emails are available elsewhere for users of the site - a NastyPerson can reasonably quickly lock your entire user base out of the system (either deliberately, or by a poorly coded password attacking bot).
If you have per-IP lockouts then you're still open to bot-nets and the problem doesn't get much better.
What seems to work best is to slow logins down rather than lock them out completely. Still lets users in, but slows down bulk attacks enough so that the risk is low.
And having nice metrics / reporting tools so that you can spot attacks as they're happening and make appropriate case-by-case responses.
Lock-outs are tricky to manage. I can flood 50 login requests and have the legitimate user quickly locked out. CAPTCHAs can help but they're annoying and it's cheap to pay people to solve them if necessary.
Forcing a CAPTCHA for a new IP address or when a "you-have-logged-on-from-this-browser-before" cookie added to a lock-out would definitely be an improvement.
Paying people to read the CAPTCHAs would not help you much with a naive brute force attack. Assuming you can break 1 CAPTCHA/second, you could hypothetically try 86400 passwords/day. Breaking a 6 character password would then take you 52^6/86400 = 228826.5 days ~= 627 years. But I bet you'd run out of money earlier! Of course, it's a different story if the CAPTCHA can be OCRed.
1) Username is not known. No reason the attacker would know this short of a leak / social profile with identical username. In this case, submitting random usernames and getting a hit should trigger a lockout and corresponding alert.
2) Username is known through system compromise. In this case, the account should be locked out and a new password generated just in case.
So I don't really see causing a deliberate account lockout as a primary attack vector other than trying to exploit weaknesses in password reset processes across multiple sites (like what happened to Dan Harmon).
Therefore, I would say that having a lockout mechanism is better than not having one.
So I don't really see causing a deliberate account lockout as a primary attack vector other than trying to exploit weaknesses in password reset processes across multiple sites (like what happened to Dan Harmon).
You're assuming that the lockout is aimed at an individual. In my experience it's aimed at the site. They're trying to lock out N% of users. In which case going for common names, email addresses, etc. will get you a surprisingly large chunk of the user base.
And that's ignoring the many sites where usernames are public, or easily accessible by a "normal" user that can be used to scrape them for the DOS/password bot.
Therefore, I would say that having a lockout mechanism is better than not having one.
Since I've seen DOS attacks that use them - I'd tend to disagree :-)
Unless you're in an environment that makes them effective.
For example my bank uses a lockout - but it has a private customer number that's not visible to others, along with a separate password and a 8 digit PIN (of which it only asks for three random digits). It's only when two of the three bits of information are correct that the lockout count starts - making bulk lockouts for the site pretty much impossible. So there it's an effective tool to prevent password cracking.
I don't need to compromise HackerNews to see your username. Many sites fall into that same category - anything with a social element, comments, profile pages.
