WebApp Sec mailing list archives
Re: Account Lockouts
From: "Jason Coombs" <jasonc () science org>
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, butSomebody 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 ======================================================================
Current thread:
- Re: Account Lockouts, (continued)
- Re: Account Lockouts Burak Bilen (Dec 02)
- Re: Account Lockouts Valdis . Kletnieks (Dec 03)
- RE: Account Lockouts David LeBlanc (Dec 02)
- RE: Account Lockouts Michael Silk (Dec 03)
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Re: Account Lockouts Valdis . Kletnieks (Dec 03)
- Message not available
- RE: Account Lockouts Skander Ben Mansour (Dec 06)