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 PROTECTED]
http://www.jasonkohles.com/
"A witty saying proves nothing." -- Voltaire
_______________________________________________
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
