Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security SecProg
[Top] [All Lists]

Re: Account Lockouts

Subject: Re: Account Lockouts
Date: Fri, 3 Dec 2004 16:48:00 +0000 GMT
Saying that we are required to tolerate all methods of access to our services 
just because those methods of access are technically possible is the same 
thinking that has led us to the modern world of computing where we are required 
to tolerate all manner of executable content including data and mobile code 
that arrive from a network just because somebody else decided they had a right 
to the 'freedom to innovate'.

Blacklist Saudi Arabia, then, if they can't figure out how to route packets 
without appearing to be an attacker.

Regards,

Jason Coombs

-----Original Message-----
From: Haroon Meer <haroon@sensepost.com>
Date: Fri, 03 Dec 2004 11:22:39 
To:Jason Coombs <jasonc@science.org>
Cc:David LeBlanc <dleblanc@exchange.microsoft.com>,       Harrison Gladden 
<hgladden@gmail.com>, webappsec@securityfocus.com,       
secprog@securityfocus.com
Subject: 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
jasonc@science.org

-----Original Message-----
From: "David LeBlanc" <dleblanc@exchange.microsoft.com>
Date: Wed, 1 Dec 2004 20:41:09 
To:"Harrison Gladden" <hgladden@gmail.com>, <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.~


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

<Prev in Thread] Current Thread [Next in Thread>