
Using memcached to rate-limit dictionary attacks - soundsop
http://www.hackszine.com/blog/archive/2009/01/using_memcached_to_ratelimit_d.html
======
tptacek
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.

~~~
timf
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.

~~~
tptacek
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.

~~~
timf
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...

~~~
tptacek
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?

~~~
timf
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.

~~~
tptacek
"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.

~~~
timf
_"IP based backoff is a speed bump"_

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.

