David A. Wheeler [mailto:dwheeler@ida.org] said:
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.
That's something that goes back to my start in the security business - I
was working for a small telephony provider, and they had their own
calling cards. One thing we looked for as a problem scenario was
multiple calls happening on the same calling card at once. If you see
someone trying to parallelize attacks on a given user by coming from
multiple addresses or sessions at once, you can then take action -
either lock out the account for a while, or substantially increase the
delay time.
Another approach would be to force logins for a given account to
serialize. So regardless of source IP, one failed attempt means you need
to wait 10 seconds before trying again. Two failed attempts goes to 20
seconds. A legitimate user who really has the password would be delayed,
but not prevented from logging in. Obviously, the code needed to do this
is a lot harder to write correctly than it is to suggest.
That's an approach which has been used successfully with certain
protocol problems, but it can be generalized to this - detect when
you're under attack, and then change behavior in a way that inflicts
more difficulty on attackers than legitimate users.
The biggest thing is not to let the users pick poorly chosen passwords.
That part takes some work, and you have to be prepared to give them
understandable guidance about just why it was a bad password, and how to
pick one that will pass your requirements. If a password won't fall to a
direct dictionary attack, and is reasonably long (IMHO, 8 characters or
more) and complex, then the attacker would need a very, very long time
at 6 cracks/minute to get anywhere.
