Re: Account Lockouts

Hi..

again this will come down to your particular situation.. all of saudi 
arabia just about comes through a single proxy.. you probably could 
whitelist it.. but then what? it means any attacker with a bounce box in 
.sa gets a get out of jail free card ?

If you are a running a banking app.. do you blacklist the company 
attacking you when a user somewhere behind the proxy decides to get 
"fiddly".. it leads to decent DoS possibilities.. secretary in fortune 
500 tries 10 bad logins and suddenly the CFO (and his whole financial 
team) cant use the bank.app either..

i personally dont think we can make any call / take any action on the IP 
address when talking web-apps.. unless you are using some sort of 
control/applet that builds a reasonably accurate, reasonably individual 
fingerprint of the "user", and in that case, you are lockign out the 
fingerprint not the ip..

/MH


Jason Coombs wrote:
>>run into problems with large proxies
>>if you use this approach, but
> 
> 
> Somebody should assemble a centralized list of these terrible beasts, large proxies.
> 
> My preference is to presume that the IP is that of an attacker first, and whitelist the known large proxies.
> 
> Jason Coombs
> [email protected]
> 
> -----Original Message-----
> From: "David LeBlanc" <[email protected]>
> Date: Wed, 1 Dec 2004 20:41:09 
> To:"Harrison Gladden" <[email protected]>, <[email protected]>,       <[email protected]>
> 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:[email protected]] 
> Sent: Wednesday, December 01, 2004 9:52 AM
> 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.~
> 

-- 
======================================================================
Haroon Meer                                                         MH
SensePost Information Security                          +27 83786 6637
PGP : http://www.sensepost.com/pgp/haroon.txt     [email protected]
======================================================================