First, have a look at the numbers: Password Recovery Speeds - How long will your password stand up
If you don't have the time to look through the tables in that link, here's the list of them:
- It takes virtually no time to crack a weak password, even if you're cracking it with an abacus
- It takes virtually no time to crack an alphanumeric 9-character password, if it is case insensitive
- It takes virtually no time to crack an intricate, symbols-and-letters-and-numbers, upper-and-lowercase password, if it is less than 8 characters long (a desktop PC can search the entire keyspace up to 7 characters in a matter of days or even hours)
- It would, however, take an inordinate amount of time to crack even a 6-character password, if you were limited to one attempt per second!
So what can we learn from these numbers?
Well, lots, but we can focus on the most important part: the fact that preventing large numbers of rapid-fire successive login attempts (ie. the brute force attack) really isn't that difficult. But preventing it right isn't as easy as it seems.
Generally speaking, you have three choices that are all effective against brute-force attacks (and dictionary attacks, but since you are already employing a strong passwords policy, they shouldn't be an issue):
- Present a CAPTCHA after N failed attempts (annoying and often ineffective)
- Locking accounts and requiring email verification after N failed attempts (this is a DoS attack waiting to happen)
- finally, login throttling: that is, setting a time delay between attempts after N failed attempts (yes, DoS attacks are still possible, but at least they are far less likely and a lot more complicated to pull off).
Best practice #1#A short time delay that increases with the number of failed attempts, like:
- 1 failed attempt = no delay
- 2 failed attempts = 2 sec delay
- 3 failed attempts = 4 sec delay
- 4 failed attempts = 8 sec delay
- 5 failed attempts = 16 sec delay
Best practice #2#A medium length time delay that goes into effect after N failed attempts, like:
- 1-4 failed attempts = no delay
- 5 failed attempts = 15-30 min delay
Best practice #3#Combining the two approaches - either a fixed, short time delay that goes into effect after N failed attempts, like:
- 1-4 failed attempts = no delay
- 5+ failed attempts = 20 sec delay
Or, an increasing delay with a fixed upper bound, like:
- 1 failed attempt = 5 sec delay
- 2 failed attempts = 15 sec delay
- 3+ failed attempts = 45 sec delay
DoS attacking this final login throttling scheme would be very impractical. And as a final touch, always allow persistent (cookie) logins (and/or a CAPTCHA-verified login form) to pass through, so legitimate users won't even be delayed while the attack is in progress. That way, the very impractical DoS attack becomes an extremely impractical attack.
Additionally, do more aggressive throttling on admin accounts, since those are the most attractive entry points
More Information#There might be more information for this subject on one of the following:
- API Service Delivery
- Best Practices Password
- Cloud Native
- LDAP and Bind Throttling
- Password Anti-Pattern
- Password Guessing Attacks
- [#1] - The definitive guide to form-based website authentication - based on information obtained 2016-08-10