Re: Account Lockouts

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 <[email protected]>
> 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.
  ----------------------------------------------------------------------