You should also remember to throttle login attempts for accounts that don't exist.
It's important not to create new attack vectors that don't already exist when implementing security features.
If you don't throttle accounts that don't exist then a brute force attempt can be used to determine which logins are valid for a given service. This information can then be combined with targeted phishing attacks, etc.
I've found 1Password (http://agilewebsolutions.com/products/1Password) to be a great solution to this. It automatically generates passwords for you and saves logins on an encrypted file. The only problem I've found with it is that when you go to use a friend's computer or a public computer you don't always know your passwords. A web service version of it would be convenient, but the security implications are obvious..
For the sake of a working solution I also just store passwords in encrypted files (using encfs, though) and stop worrying about accessing everything from my non-main computers.
Script for new passwords follows, for the fun of it. I have stuff added afterwards to save the username, website, and password to encrypted files.
#!/usr/bin/env python
import string
from random import Random
okchars = string.letters + string.digits + "!@%^_&*+-"
print ''.join( Random().sample(okchars, 40) )
I assume you'd have to just sleep before sending the response. But this could tie up all available threads for processing requests and bring down the site under heavy attack.
You refuse to allow login during the delay period. That is, after the 5th failed login, for the next 16 seconds, if the user tries to login, you say "Wait sometime before trying again." You do not accept and check the credentials supplied during this time. You simply refuse to begin the authentication process until the delay period has elapsed.
And exponential backoff is fine but not when it gets to be too much, it turns into a DoS problem. You could try to key it by IP and never let it go past, say, 2 minutes per source IP.
i.e., if me simply knowing someone's account name lets me disable their account for the next day or longer, that's a big problem.
It's not just tying up threads you want to avoid but any unreasonable resource consumption you can. You maybe for example want to make sure the delay timeout you store for that account (by comparing current time to a "notBefore" timestamp or what not) is not going to cause a DB lookup each time, etc.
As described I don't really see how the solution proposed handles DoS attacks any better than a lock out after x failed attempts.
The key to preventing DoS attacks is that the throttling is specific to a given host so that when the genuine user attempts to log on (presumably from a different host than the attacker) they can do so without any throttling.
The Plague: Our recent unknown intruder penetrated using the superuser account, giving him access to our whole system.
Margo: Precisely what you're paid to prevent.
The Plague: Someone didn't bother reading my carefully prepared memo on commonly-used passwords. Now, then, as I so meticulously pointed out, the four most-used passwords are: love, sex, secret, and...
Margo: [glares at The Plague]
The Plague: God. So, would your holiness care to change her password?
It's important not to create new attack vectors that don't already exist when implementing security features.
If you don't throttle accounts that don't exist then a brute force attempt can be used to determine which logins are valid for a given service. This information can then be combined with targeted phishing attacks, etc.