Number of attempts to brute force an average password / non intrusive yet meaningful limits?

Question

There are several useful answers on SO regarding prevention of brute forcing a password of a web service by applying throttling. I couldn\'t find any good numbers though and I h

Answer 1

From the question it sounds like the fastest they could possibly try passwords is 50 per minute. Based on that and using random 6 digit passwords:

• all lower case: 26^6 = 308,915,776 possible passwords = worst case 12 years, 6 years on average
• lower case and numbers: 36^6 = 82 years max, 41 years on average

Of course, dictionary attacks would be much faster, but I don't have the numbers for that.

EDIT: I tried to link Google calculator results backing this up, but ^ seems to mess up links on here.

EDIT2:

Dictionary attacks (from http://www.outpost9.com/files/WordLists.html):

• all listed words (75,000): ~1 day
• list of 816 common passwords: ~16 minutes
• really long word list: ~12 days (I looked at this and I'm guessing it contains most non-technical people's passwords)

The last one is scary, but 12 days is still a long time. If you're really worried, you could track every incorrect password until the user gets a correct password, then if the list gets to over like 100 different attempts, just ban the IP address and send an email to the user.

Answer 2

You have a couple of good controls there, but you really should tighten it more. A regular user shouldn't fail to log in more than five times. If he does, show him a CAPTCHA.

Remember that under no circumstances should you lock the account. It's called an account lockout vulnerability. This allows an arbitrary user to log out other users from the service (DOS, denial of service).

I've approached this problem of login throttling many times and the one I like is that you create a field of failed attempts and the last failed attempt date in your database. Whenever someone (anyone) fails to log into account X, you increase the value of X's failed attempts and update the last failed attempt date. If the failed attempt count exceeds Y (for example, five), then show a CAPTCHA for the specific user. So, you won't have a huge database of banned IPs to throttle the login form, instead you have just two more fields per user. It also makes little sense to ban/throttle based on IPs, because of botnets and proxies (both legal and illegal ones). When IPv6 comes out in fashion, you will be more doomed I presume. It makes much more sense to throttle based on targeted accounts. So, when your account X is being targeted by a botnet, the login form will be throttled with a CAPTCHA. The obvious drawback here is that if your CAPTCHA fails... so does your login throttling.

So, in the essence it goes like this:

• Someone failed to log into account X - increase the failed attempts field.
• If there are more than 5 failed attempts, and the last failed attempt happened one hour ago, it's seems that the account is under attack, show the CAPTCHA.
• On the other hand, if the last failed attempt occured more than a day ago, it seems that the attack has ended, lower your shields and don't require CAPTCHA.

It's basically a shield that turns on when there's a massive targeted attack against particular accounts. The good thing about this kind of approach is that it won't matter if I own a farm of PCs across the world - I can't brute force a single account because it's account based.

The two bad things about this is that if the CAPTCHA fails you have nothing left. You could of course improve this situation by placing other protections, too. The second problem is that if I had a bot-net, I could use one PC per one account, and then it's likely that with a million computer network I crack at least one account, but this approach works only in non-targeted attacks.

I hope this gave you some thoughts.

Answer 3

I generally like @Tower's answer, but prefer a variant that doesn't use CAPTCHA, mostly because I hate it as a user experience.

In addition to his fail tracking fields, also add a lockout field with a timestamp. I agree that locking out a user forever (or until manual reset) makes for a bad experience, but locking out an account for an hour (while mildly painful) is an effective deterrent.

The change would then be that when the fail count is incremented beyond the threshold, the lockout field is set to now + 1 hour. Whenever auth is being performed, it looks at this field and if lockout > now, then it fails.

Manually locking out accounts from an administrative perspective then becomes just a matter of setting the lockout field to some distant future value like 9223372036854775807l (max 64-bit signed long).