[Catalyst] Rate limiting password attacks

[Jason Kohles]

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  
> identifiers.
>
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  
of usernames.

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

-- 
Jason Kohles
email at jasonkohles.com
http://www.jasonkohles.com/
"A witty saying proves nothing."  -- Voltaire