RE: Account Lockouts

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:[email protected]] 
Sent: Wednesday, December 01, 2004 6:52 PM
To: [email protected]; [email protected]
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 <[email protected]>
Computer Engineer & Science Major
~Past experience: He who never makes 
   mistakes, never did anything that's worth.~