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.
----------------------------------------------------------------------
