This dictionary attack thing is getting a little silly. Most sites do not go through contortions to solve this problem, but aren't especially vulnerable --- just lock users out for a couple hours on the Nth bad guess, and let the real user override the lockout with the password reset mechanism, which is a risk you're accepting already.
What happened to Twitter was a failure of policy, not a failure of technology.
I don't understand the "override lockout" part? If a user overrides a lockout and gets a new password, what is to stop the lockout process from starting over again as the attackers continue trying.
I don't think that "security question + get in immediately" is the answer either. Security questions are just other, usually significantly weaker passwords.
So do you mean password reset with an email that contains a special link that does allow them in? (not that email is great but it's at least another channel)
I think an exponential backoff with a maximum of somewhere in the 2-5 minutes range per IP would be ok.
> If a user overrides a lockout and gets a new password, what is to stop the lockout process from starting over again as the attackers continue trying.
The fact that the password reset changes the password. So the brute-force attack would need to start over to be 100% successful. With the rate-limiting, and the user being forced to change the password via password reset, a brute-force attack becomes near impossible.
Understood and I agree, but that's not the problem I'm trying to address. If the user needs to know what is going on and needs to reset a password, I want this to be at the very latest possible time (like days or weeks into the problem).
You have a password reset anyways. Usually, it's email with a long nonce URL; security questions are what not to do. But one way or another, you will end up with password reset, or you'll burn headcount on dedicated CSRs just to reset f'ing passwords.
Don't do something special for lockout; just offer a link to the password reset page in the lockout error message, and reset lockout when the password changes. You've employed a second (also weak) authentication factor when you did the email exchange, so your user attested it's ok to undo lockout.
As for "they'll just lock you out again", there is no solution to that problem. If you're using some funky backoff scheme, the same attacker keeps you out by keeping the backoff high.
If the lockout is based on IP, there's a very high chance I can hide this from users because there's a very high chance that the nuisance is not coming from the IP the user is logging in with.
If my app starts getting attacked with password guessing scripts every day with correct account usernames, the users involved would need to be constantly doing this email based reset scheme.
Personally, if this happened to me every time I logged in and there was an alternative to the service, I would take my business elsewhere...
I have zero faith in IP-based login reputation. Within the next couple years, the Internet will have a constant ambient stream of dictionary attempts on every web app that anybody knows about; that attack tool is very easy to write, and has a high payout (every Last.fm password is 60% likely to yield a gmail or ymail account). The dumbest attackers on the Internet are already smart enough to spread attacks over hundreds of IP addresses.
The sites that are going to get targeted are the ones that don't do lockout. The ones that do will be worthless, except to get your bots killed.
What are you really accomplishing by trying to make this seamless backoff system?
Make it reverse. Give known IP addresses a better reputation that unknown.
Consider four zones: 1: the last three IP addresses the user has used; 2: any IP address the user has used more than 5 times; 3: any visit that has a valid "I've been logged in as user NN" cookie (given with expiry:never on every login); and 4: everything else.
Lockouts are per zone. Chances are that your average automated attacker is always in zone 4, and that your legitimate user is always in zones 1-3, and that they'll never bother each other. You can then make a policy that's three tries and you're out for three hours, unless you verify your e-mail address. 24 tries a day should be low enough that dictionary attacks are infeasible.
What does reputation have to do with anything? I'm not saying the lockout would be based on an IP database but rather the # of attempts would be scoped by the IP address it was originating from. At some point you could completely lock out attempts from that IP. Sorry if that was unclear.
This means that there in almost all cases the IP used by the bona fide customer would not be in locked out mode or in exponentially backing off mode yet.
I understand relying on different IPs is not going to work 100% of the time, spoofing and NATs etc. are a (small) problem in this scheme. In such cases, the "locked out" message will be displayed and the bona fide user will get his email anyhow. (I guess if the attacker was just trying to be annoying to someone, he could hit the 'locked out' button over and over again, is that the point you are trying to make?)
What I am saying is that I do not want the user to have to bother with resetting their password until the last moment. The fact that this is not a "bulletproof" solution is not an issue. Getting things down to much less likely is a win in this case because it means the customer's experience has been enhanced (or rather, has not been un-enhanced).
"The sites that are going to get targeted are the ones that don't do lockout. The ones that do will be worthless, except to get your bots killed."
I don't get the reasoning here. I want a system that both discourages getting specifically targetted like you are saying -- but also one that has a contingency plan if there is an attack.
What we seem to be disagreeing about is the contents of that contingency plan? You want a simple one and I want one that will try to avoid the customer needing to even know there was a problem if possible.
"Reputation" is what the banks call this same solution, although it's just as silly there.
My reasoning is, your solution is weak, and my solution isn't. Most user accounts are rarely or never used. IP based backoff is a speed bump for a coordinated attack against those accounts. Lockout completely stops it. And lockout is much easier to implement, which was my original point: people are wasting too much time thinking about this problem, and coming up with weird results.
Exactly what I want from it. Speed bumps solve problems. Locking your car doors solves a problem. Neither guarantee anything but both have real effects which make people's lives better.
That is, there can be another "N" here where the account gets shut down completely. If it ends up happening against one account from more than, say, 50 different IPs then shut it down and resort to inconveniencing the real user. Let's say 8 tries * 50 IPs, 400 is the new N where total cutoff happens. Too high?
This makes it more likely that the bona fide customer won't be bothered by stupid script kiddies.
So I assume via your company that you have field experience with people using this scheme. How often do their users need to go through that reset?
I think it's a terrible thing to happen to users, hoping there is a way to make it less likely (the users I am going to accomodate will not necessarily be technology fluent).
Just to note, something important I am trying to preserve is trying not to inconvenience the end user at all if possible. They shouldn't need to be bothered by this (inevitable) crap.
"If a user overrides a lockout and gets a new password, what is to stop the lockout process from starting over again as the attackers continue trying."
Nothing stops that. However, if the password has to be reset to a random string every 20 attempts before you can do the 21st attempt (say, in a day), then it hardly matters how vulnerable it was originally.
Nothing ultimately stops that but I am hoping a per-IP approach to lockouts will relieve my bona fide users from needing to go through a tedious reset process (potentially often).
If you backoff to 5 minutes max per IP that leaves 288 tries a day per IP (well, slightly more because of the part where it backs off). With eight character minimum passwords, someone with a botnet would have to have probably thousands and thousands of unique IPs at their disposable to even being successfully brute forcing...?
The existence of botnets does complicate matters, though, as you note. In general, I don't agree that this is a matter for site designers; the more we try to protect the users from themselves, the more it will be our liability when we ultimately fail (and we will fail in the end).
Making a song and a dance of this isn't necessarily a bad thing if it shines a light into some of the dark places of bad practice.
Frankly I can put up with a week of posts about some rudimentary security if it means some of my favorite services are more secure. Not that I'm silly enough to use a dictionary based password.
What happened to Twitter was a failure of policy, not a failure of technology.