Is there any risk in allowing more failed login attempts before autobanning for a longer time?

Question

Most software and services seem to have low "burst" settings, like 3 to 5 login attempts before a temporary autoban for a couple minutes. Especially banks have a very low limit before access is denied.

I find this very annoying and, when possible, I always set it to allow 15 (or more) login attempts. My password are non-dictionary and brute-forcing in under 15 attempts is out of the question. If you have a number of passwords that are possible, for example from looking over my shoulder, you'll probably still need quite a few attempts. In some cases, benign software automatically attempts a number of logins (e.g. Filezilla FTP), making you trigger the autoban already because of that.

When configuring a higher number of failed login attempts, I also configure it to ban for a longer period (e.g. 24 hours instead of a few minutes). Surely that's no legitimate user, or they really did forget their password and need to reset anyway.

Why don't more websites and software do this by default? By now I have a pretty long (mental) list of passwords that I use. After not using a service for a while, it might be any of at least 3 different passwords, each having 2 or 3 variations, and each variation needs to be typed twice to be sure you typed it correctly. Additionally, the services that allow only 3 attempts are usually also the ones that enforce ridiculous passwords (8 character uppercase, lowercase, digit, special character, no spaces, no longer than 12 characters... try remembering what permutation you used there to make this work).

Same goes for delaying login attempts, FritzBox routers are really good at this. One failed attempt is 8 seconds delay, the next 16, the next 32... really great, except my fat fingers might end up getting me a delay of 16 seconds while I only had two failed attempts. I'd rather like that it limits me to two attempts per second and jumps to 300 seconds delay after 10 attempts.

Why does lots of software default to only a few login attempts and short bans, instead of a higher number of logins and a long ban? The latter seems much more practical to me. Is there any valid security reason behind this, or is it just another of those common practices that are there because they made sense at some point in history?

Answer 1

1. A lot of people have very short very weak passwords - 40% of all users share the same 100 passwords, 14% share the same 10 passwords (see article). So even a 10 or 20 passwords may suffice for an attacker trawling multiple user accounts. Hence the low cutoff bar.

2. If the user is legit and has simply mistyped their password several times, they have probably forgotten it. Some organizations like to be directly contacted for password reset, despite the possible support overhead.

3. While I personally like exponential time-locks; unless an organization has 24/7 tech support, timelocks will turn into normal user lockouts on a weekend. Additionally a distributed attack across multiple users at once may rearrange the exponential delays sufficiently that, on a bell curve, some user account will be cracked well before the exponential delay for a single user would imply.

4. The organisation may assume that a denial of service is either sufficiently resolvable or unlikely enough that a DDoS lock out of all users is a low concern.

5. An organization may feel that the user's access to their service is a privilege and the user or service's information is more valuable than the user's ability to access it. Hence a priority toward operational security instead of user convenience. Afterall the actual users are rarely invited as direct stakeholders in the software design workshops.

6. Initial solutions for Points 1 - 5 were made on early computer systems and then often copied as "good enough" for computer systems made decades later. The original systems involving remote login were military and university projects; where the user was a supplicant not a customer.

Answer 2

I would not generalize your password picking abilities to the general public. Users will often reuse weak passwords and maybe they could be guessed.

There is also the support consideration. Let's say you lock someone out after 5 bad attempts for 20 minutes. Maybe after the attack get's locked out it moved onto another account, that means after 20 minutes the account is now open to the real user. That is a realtively short interval, but within a 24 hour period, the legitimate user would still be blocked. They now have to call support to have their account unlocked and they may also panic. From a user support standpoint, perhaps they would rather reduce manual unlock call volume.

Or more likely, they are just doing what "everyone else" is doing or what they think is common knowledge. It's also possible "some auditor" told them to do it. An exponential backoff may be a good technique to a point, but that sounds like a few more lines of code to manage[sarcastic, but in a large org there may be a real dollar cost associated with even such a small change]; unlikely, but possible storing/processing a time and count during a bot based attack for the exponential backoff could have a negative effect on performance at scale.

Answer 3

One short answer for your question is to mitigate the risk of DoS to actual users by not disabling the account for a long period. By sites differ in their C.I.A. requirements and what works for one may not be applicable for another.

Answer 4

As to your basic question, you have to consider the ramifications of each scheme. The exact timings have more to do with paranoia and tech-support call volume than formal security analysis.

In terms of brute forcing, you have to try LOTS of attempts. Offline brute forcing attempts are able to recover 90%+ of passwords because they are running at hundreds of thousands or millions of passwords per second. Users may share passwords, but even a 5 minute ban effectively throttles the brute force attempts down to 1 password/minute. On top of that, attackers generally don't have access to all of the user names. Throw-in IP blacklists of known spam-bots and it's a really impractical attack. Hackers would have a much easier time just sniffing network traffic and logging keystrokes using a virus.

A five-ten minute ban is shorter than the time required for a customer to contact tech support. If the user can't figure it out after (for example) 3 bans, then the user is likely to contact customer support or reset their password as they have probably forgotten it anyway. So what's the point of banning them for 24/hours using a complex scheme? That's just going to frustrate an already frustrated user.

More complex schemes might make sense for Wordpress and other frameworks which don't have dedicated teams filtering out the spam bots. However, most of these types of frameworks send their passwords over plain text and would be better off just outsourcing user identification to Google/Yahoo/Mozilla anyway.

For banks and other high-value targets, such complex schemes are enforced because the attackers are motivated to perform similarly sophisticated attacks. The frustrating instances occur when the lone-IT-admin for an organization has both paranoia and the lack of giving-a-shit about the end user. To them, they figure that if they capable of memorizing complex passwords or using password management software, why can't the end user?