Heya. The question makes perfectly sense. Let's hope my answer
won't cause undue confusion on anyone's part. :)
Hmm, what if, after X failed logons in Y seconds, the system would
require the user to write a certain text string into another input
box for that login attempt to be handled? And the extra string
would be displayed on the login page in a way not easily understood
by an automated script, e.g. in a small image?
Much like the "human authenticator" I've seen some web based systems
use (unfortunately, I can't recall exactly where I saw it). I have no
idea how hard it would be to implement, but it's a thought, at least.
Regarding having the users pick their own names - you didn't say
where the application is deployed, but if it's an internal one in a
large organisation, I'd say you'll have a greater administrative
headache by going away from the standard. Not to mention increased
complexity if you want SSO sometime in the future. If I further assume
that the application already exist, you will probably annoy many of
your existing users if you force them to change usernames (and what's
to stop them from setting the same name again?)
A timeout on the lockout is perhaps easier. Nothing to stop an attacker
to run the script continously, but in that case, the perpetrator might
be traced or blacklisted on IP level. Or, if an internal one,
administrative action taken.
Also, you'll have do decide whether the login form should say "Account
locked" or not. Silently ignoring the login might be more secure, but
will give your support team more work. One could also process the login
as usual, and log the attempt, just to see if a correct password was
supplied, but skip the last step of authentication (letting the
user in). This would place extra load on the authentication server (which
I assume is separated from the web application), but provide extra clues
on the success of the brute-forcer. This assumes your organisation actively
monitors your logs, else it won't do you any good (obviously). This method
will also make it harder for a savvy attacker to deduce lockout in progress
my measuring response times. Of course, if your users already know
that account lockout will occur after X failed logins, then there's no
point.
Best regards,
Patrik Sternudd
-----Original Message-----
From: Harrison Gladden [mailto:hgladden@gmail.com]
Sent: Wednesday, December 01, 2004 6:52 PM
To: webappsec@securityfocus.com; secprog@securityfocus.com
Subject: Account Lockouts
Hello all,
My question to the group is about handling account lock outs. Here's
the situation, assume there is a web interface that lets users log in
and do stuff, but the log-in process is constrained by the network
restrictions as well.. Meaning if a user tries to log in X times in Y
seconds and fails each time, then the account get locked out.
What are successfull techniques that could be used on the web
interface to avoid having a script run against it that would
potentially lock out 15000 user accounts, and create a headache for
the system administrators who have to manually unlock each account?
Also assume the current user account names are known by everyone.
Possible techniques we've thrown around:
1) Allow each user to pick their own username instead of using a
standard (i.e. First 3 letters of first name + Full last name)
2) Create a set time-out period for each account of X (maybe an hour)
Hopefully my question makes sense.
Thanks,
Harrison
--
___________________________________
Harrison Gladden <hgladden@gmail.com>
Computer Engineer & Science Major
~Past experience: He who never makes
mistakes, never did anything that's worth.~
