[Catalyst] Rate limiting password attacks
email at jasonkohles.com
Fri Aug 17 19:12:21 GMT 2007
On Aug 17, 2007, at 10:56 AM, Carl Johnstone wrote:
>> Anyone doing something like this already? Suggestions? Caveats?
> You'll almost certainly have to log it per-IP address rather than
> an a cookie or session or anything like that. Any real password-
> cracking bot is unlikely to honour your cookies or session
Real password cracking bots tend to use gigantic lists of open
proxies, which defeats the IP logging as well.
> Which in return means you'll need to be careful, you don't want to
> block AOL users from logging in, just because a few of them all
> forgot their passwords within a few minutes of each other.
One way to try and avoid this problem, is to key it by IP and
username, password cracking bots usually try one username with a
dictionary of passwords, rather than one password with a dictionary
> As an idea, how about adding an (increasing) artificial delay into
> the response when the clients send an invalid username/password. It
> would make things increasingly awkward for crackers, whilst still
> letting good users through. A suggestion though it wouldn't work
> very well in mod_perl or similar setups where you can't afford to
> tie up system resources holding onto client connections.
Instead of delaying the response, one possibility is to send a
complete response without a login form, just a note that says 'too
many attempts, try again in X seconds', possibly with a refresh to
reload the page once the timer expires. This way you don't hold the
client connections open while waiting for the timer to expire,
although then it means you have to track on the server side when that
timer will expire so you can start delivering the form again.
Adding a delay is useful for console applications, where the user is
forced to wait for the delay before trying again, but not so useful
for web applications, where a cracker can just hold a few thousand
connections open while waiting for the delay to expire.
I've been contemplating the best way to address this problem on some
of my own sites, and unfortunately I always end up back at the
CAPTCHA approach. I don't really like forcing users to solve a
CAPTCHA every time they log in, but so far it's the only solution
that I've come up with that doesn't also turn into a massive denial
of service potential when people start intentionally sending bad
passwords for people they don't like.
email at jasonkohles.com
"A witty saying proves nothing." -- Voltaire
More information about the Catalyst