Harrison Gladden asked on 2 Dec 2004:
> 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?
Remember, the real goal is to make password guessing impractical.
Anything you do is fine, as long as you practically achieve
your real goal without greater harm to some other goal.
You can make the lockout times quite short,
or even not have lockouts at all, if you can do something
else to make password guessing impractical. For example:
* Don't allow users to set easily-guessed passwords;
just reject them, and don't let users log in until
they've selected a good one or you've auto-created
a good one for them. Users may be more likely to
write them down; if you're primarily worried about
network-based guessing attacks, that may be a good trade.
I don't like letting the system select your password;
I prefer checking the password to ensure it's okay.
* Don't lock out if the user logs in using the console
and/or trusted IP addresses and/or "last IP address"
Obviously, this opens you up to password guessing attacks
if an attacker is in those IP address ranges, and a
good attacker spoof an IP address too
(so you want to combine this with other techniques).
* Lock out only a given IP range (typically a.b.c.*), and
require the use of TCP to make it harder for an attacker
to really create a vast set of IP addresses to use.
* Shorten the lock-out time. If the password is hard to guess,
a lock-out of 5 seconds will still make it extremely
difficult to guess the password in your lifetime.
Watch out for parallel logins, though.
This can still mean that an attacker can always lock out
everyone, but only during the duration of an attack;
halt the attack & the lockouts cease quickly.
* Delay any password verification. E.G.:
accept_password(); wait(2 seconds); check_password();
Again, this makes password guessing attacks really hard to
execute in reasonable time. Make sure that people
can't do thousands of logins in parallel, though, or this
is easy to work around.
There are lots of other obvious ways to (partly) deal with this.
If I were you, I'd probably combine several of the above
techniques, depending on the situation.
E.g., require the user to select a good password,
don't lock out the IP address they successfully logged in to
last time, always delay password verification (e.g., 2 seconds)
with a limited number of simultaneous logins, and
have a very brief lock-out (say 10 seconds).
By itself, short lock-out times aren't that great,
but if you combine it with other approaches they may
work well for you. You're actually better off worrying
about making the user select a good password FIRST;
then the other stuff is less important.
There's no free lunch. Lock-outs make it harder to gain
entry by attackers, but also create a denial-of-service
opportunity for attackers. You need to consider your
specific circumstances to figure out what the
best balance is.
--- David A. Wheeler
