WebApp Sec mailing list archives
RE: Account Lockouts
From: Stephen de Vries <stephen () corsaire com>
Date: Fri, 3 Dec 2004 10:31:54 +0000
Hi Harrison,It's a tricky problem and the possible solutions all have their own set of pros and cons. The one appropriate for you will depend on the security and business requirements of the app as well as the operational constraints of your environment. For example, implementing one solution might make it more likely that an account is brute forced, but at least the site stays available for all users and your operations team don't have to manually unlock accounts.
You mention:
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)
Yes, that's a given, being able to enumerate the usernames on a site is the first step in either a) brute forcing an account or b) locking out valid accounts. In addition to this, you could go a long way towards preventing brute force attacks by requiring your users to choose strong passwords. There was a post previously on this list about brute force attacks targeted against the username and not the password, e.g. attempt all usernames with the password "password". Even if you have a lockout of 3 failed attempts, it still gives the attacker the opportunity of choosing 3 common passwords...
2) Create a set time-out period for each account of X (maybe an hour)
Or you could use an incremental timeout period, e.g. after 3 failed attempts, user is locked out for 10 minutes, after another failed attempt, they're locked out for 20, then 40 etc. PROS: Limited intervention from the operations team - the lockout and unlocking is handled by the app. CONS: You're providing an attacker with more opportunity to the guess the password - they just need to change their attack a little and they could still squeeze in 10 attempts in 24 hours (just an example - it's too early to do the math). The escalating value could still be an effective DoS, since the attacker only needs to keep up with the lockout process to effectively lock the account out for a long time period. To prevent this, it's a good idea to have a ceiling that will lock the account out permanently and send an alert to the operations people.
Another solution is to use a CAPTCHA (www.captcha.net) like system on the login page. This will thwart (or challenge) any automated attacks against the app.
PROS: Stops both brute forcing and account lockout attacks.CONS: It's an extra step to the authentication process. If you have a large untamed user base they may find this annoying. And you're almost guaranteed to meet resistance from the business when suggesting this solution.
In addition to these you should definitely have backend processes in place to both detect and deal with automated attacks. Depending on your development budget, detecting an attack could be simple checks based on the IP address (which can be foiled by using the plethora of open web proxies on the net) - to sophisticated statistical analysis - it all depends on how much of a risk you believe this type of attack poses. On the operational side of things - the mechanism implemented to unlock accounts (usually support personnel) should be aware of the possibility of lockout attacks and should know what procedure to follow when they suddenly start receiving hundreds of calls from users whose accounts have been locked out. To deal with attacks you should have a backend script that easily unlocks all accounts in the event of a lockout attack. It could also be useful to have the ability of denying access to your site based on IP address - although this should be used with caution to prevent accidental lockout of legitimate users sharing the same proxy as the attacker.
Also take into account the type of attacker that poses the biggest threat - are they random attackers that are happy to target some site, any site and just happen to pick yours; or are they specifically targeting your site. In the case of the former, you just need to make your application that much harder to attack than any competing site and the attackers will pick an easier victim. The latter present more of a challenge and you may need to dig deep into those development budgets to build sophisticated protection mechanisms into your app.
Regards, Stephen
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.~
---------------------------------------------------------------------- CONFIDENTIALITY: This e-mail and any files transmitted with it are confidential and intended solely for the use of the recipient(s) only. Any review, retransmission, dissemination or other use of, or taking any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you have received this e-mail in error please notify the sender immediately and destroy the material whether stored on a computer or otherwise. ---------------------------------------------------------------------- DISCLAIMER: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of Corsaire Limited, unless otherwise specifically stated. ----------------------------------------------------------------------
Current thread:
- Account Lockouts Harrison Gladden (Dec 01)
- Re: Account Lockouts Burak Bilen (Dec 02)
- Re: Account Lockouts Valdis . Kletnieks (Dec 03)
- <Possible follow-ups>
- 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)