RE: Account Lockouts

["Matt Fisher" <mfisher () spidynamics com>]

Some thoughts on this: 

For an external Internet facing application, relating anything to the IP
address is difficult at best, given the megaproxy scenario.  I haven't
looked into it lately, but several years ago (last time I researched it)
AOL sent all their web traffic through a very small number of proxies.
Assuming they're still the largest consumer ISP, that would definitely
create issues.  There have been previous threads on session binding that
discuss variations of this, such as binding to domain name, etc.  For
internal applications, it can work nicely assuming every host has a
unique IP (which may not be the proper assumption).

Its also trivial to rotate requests through multiple proxies, stagger
timing, etc. to evade this sort of issue as it relates to account
lockouts. 

Under the assumption that all the usernames are known, it would be
difficult to protect them.  Obviously it will come down to locking and
unlocking accounts and as David said, if the asset is particularly
important than you want to increase the level of effort required for an
unlock.  Of course, this can be a DoS in itself .... Someone just
scripts an attack to lock all your accounts in the middle of the night,
and the next morning the call center is slammed.  If the accounts are
unlocked automatically, a determined cracker will discover this as well,
and simply change their script to accommodate the duration.

When creating lockout mechanisms, you may want to consider lockouts
based not only on the number of attempts per account, but also the
number of attempts per password.  Mark Burnett brought up an interesting
attack scenario in his book Hacking the Code (excellent book): you can
beat up a single account with lots of passwords, which would surely
lockout the account if you didn't succeed quickly, or you can simply
pick a very probably password (i.e. "bigbank1") and try that one
password across multiple accounts.  Rarely would this lock out any
accounts on most sites I've seen, and could very well be just as
effective in finding the right uid/pw combination.  Of course, if
handling lockouts based on uid is problematic, doing it based on
passwords is even more so.  

Randomness in the user ids is always a good thing; you want to break the
assumption that your uids are known.  Most userids that are "handed
down" versus created by the user tend to follow extremely predictable
naming conventions - and often times they're the same naming convention
used as email accounts as well.   

Use of CAPTCHA in logins is recommended as well to mitigate brute force
attacks.  Certainly use them for any automated account unlocking
mechanisms as well.  

- Matt. 



> -----Original Message-----
> From: David LeBlanc [mailto:dleblanc () exchange microsoft com] 
> Sent: Wednesday, December 01, 2004 11:41 PM
> To: Harrison Gladden; webappsec () securityfocus com; 
> secprog () securityfocus com
> Subject: RE: Account Lockouts
>
> This depends on the asset you're trying to protect. If it is 
> a bank, maybe I want to force someone to call.
>
> This would be hard to implement, but if you could also track 
> the source IP of the logon, you could then only allow some 
> small number of user names to be tried from any one IP 
> address. Won't protect you from an army of bots, but ought to 
> get rid of most of the anklebiters. You may run into problems 
> with large proxies if you use this approach, but again, this 
> depends on your use scenario.
>
> Injecting some randomization into the user names would make 
> sense. Make the attacker guess as much as possible.
>
> -----Original Message-----
> From: Harrison Gladden [mailto:hgladden () gmail com]
> Sent: Wednesday, December 01, 2004 9:52 AM
> 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.~