Are password-guessing attacks a real threat?

Question

There are tons of questions, answers, articles, papers, cartoons etc. on the subject of how to choose a password in such a way that it's difficult to guess or crack with a dictionary-based attack.

I don't understand why a system would allow me to try that kind of attack in the first place, so I'm wondering what it is that I am missing about that type of attack - or any other type of attack that entails trying gazillions of different passwords until one works.

Why would anyone want a system to allow hundreds or even millions of login attempts with the same username and different passwords in a relatively short amount of time? I appreciate to be given some slack if I can't remember my password or if I miss the right key when I type it, but I don't need - nor want - to be allowed to try and fail 100 times with the same username, and at full speed.

In other words, how difficult would it be to design a system such that after a failed login attempt the next one cannot take place before an amount of time is elapsed that is proportional to the number of failed logins for that username? I'm thinking tenths of seconds or something like one more second per each failed attempt, which would not impact a real user's attempts but in my understanding would severely limit the feasibility of dictionary attacks.

In general, except a few niches that I can imagine to exist, wouldn't it be relatively trivial and harmless for the vast majority of systems to make this kind of attacks unfeasible?

Answer 1

Depends what you're defending against, really.

1. Trying to log into a web application, attempts should indeed be restricted in some way. IP rate restriction is a good start, username level rate restriction is better, combining the two is even better. However, imagine that I have a long list of usernames and passwords from a previous unrelated breach. If I have access to a botnet (go on the darknet and browse for a few minutes - you can buy access for a while) and a little bit of programming knowledge, I can easily set up a situation where each IP address tries a single username with a single password, then waits for a while before trying a different username and password. Given enough machines, I'd be fairly confident of getting a hit with a handful of common passwords and a reasonably large list of usernames.

   If the passwords are all strong, though, it'll take me a lot longer, meaning there is a much greater chance of someone noticing the attack.

2. Trying to break accounts following a breach. In this case, any systems you have in place for restricting the speed of attack are bypassed. I have a copy of the password hashes, so I can throw them into my password cracking rig and wait for a while. The common passwords will again be the first to break, with the really strong ones taking ages (these are big ages. Think geological ages, rather than waiting for a pizza delivery ages).

   In this case, I don't care about your restrictions. I might have got the breach data without you noticing, in which case, I can just log in with the passwords I find and clear out whatever is of value in those accounts. Or you might have spotted that I got your data, in which case I'm racing against the legitimate owners to log in first. Either way, it only takes me a single try to get in if I am going to.

In case 1, it adds complexity to the attack, but also adds complexity to the authentication method. Sadly, complexity in code tends to increase the number of issues, so you would want to be sure it didn't have unwanted side effects, like timing attacks, or DoS potential (imagine that I have a shared IP, such as a mobile provider might use, and I cause it to be blocked for a peak use period).

In case 2, it is irrelevent. Doesn't matter to me. Never see it.

As with everything in security, it's a matter of balancing risks. If you have high value accounts, it is worth putting more hoops to jump through, but you should be able to afford a very strict testing process. If you have low value accounts, it might be safer to live with that risk, in order to prevent other attack vectors from working.

Answer 2

The system is to blame for a breach in the system. If they allow millions of logins per second, and an unauthorized user gained access then IMO that's on them. If the system decides to not encrypt persons private data (looking at you OPM) then this blame is on the system. Using outdated operating systems and software; that blame is on the system. I think you get the point.

However, the user has a responsibility to themselves to secure their account from a breach. The password provided is most likely used to derive a key that encrypts and secures their private information. If a system has properly secured its data then any account information that is taken is protected. If a user chooses a bad password that lets the attacker gain access to their private data that cannot be blamed on the system.

Systems have vulnerabilities. No matter how advanced or well protected. They can do their best to mitigate breaches, but passing blame to them when an account is stolen because a user decided to use "password" to me is bogus.