1

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?

Deer Hunter
  • 5,297
  • 5
  • 33
  • 50
SantiBailors
  • 391
  • 2
  • 11
  • Both. Password reuse in third party insecure systems will allow access in one try when they use the existing password databases they've gotten against your users. – Natanael Feb 03 '16 at 12:29
  • @Natanael My question is only about password guessing, that is something where the supposed weakness ("guessability") of a password comes into play. Password reuse - or anything involving any knowledge of existing passwords - is not relevant to my question. – SantiBailors Feb 03 '16 at 12:43
  • 1
    Many systems are designed to prevent online brute-force attempts. But that's not the threat an unguessable password protects against. – schroeder Feb 07 '16 at 16:21

2 Answers2

6

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.

Community
  • 1
Matthew
  • 27,233
  • 7
  • 87
  • 101
  • I see. However both scenarios require a preexisting breach to have taken place. So would it be correct to say that - without any preexisting breach and without any knowledge of real passwords - a password-guessing attack which succeeds after trying thousands of passwords is 99% to blame on the system ? (I didn't say 100% only because if my password is "hello" I'm to blame even if the attacker for some reason tries that after many thousands). I understand that this absence is not realistic but I want to know how much preexisting breaches contribute to the need for protecting from pw-guessing. – SantiBailors Feb 03 '16 at 13:15
  • 1
    I'm not really convinced - there is no need to have a previous breach if you guess at things that might be common. For example, there is quite often an "admin" account for systems. You can pick common names and turn them into username: johnsmith, jsmith, john.smith, etc. You can use predictable passwords: password, Password1, qwertyuiop. The previous breaches (which already exist) help, but essentially just provide a starting point. – Matthew Feb 03 '16 at 13:29
  • I had mentioned the requirement of a previous breach only because both your scenarios seemed to me to be based on that requirement. I agree with you that there is no need to have a previous breach if you guess at things that might be common. – SantiBailors Feb 07 '16 at 13:43
  • What I'm trying to understand with my question is why systems don't make password-guessing attacks unfeasible by preventing repeated login attempts with same username or IP or such. If I understood correctly your answer about that is that a) it's more difficult than it sounds because one could attack using varied usernames and IPs, and b) introducing things like delays between attempts makes the system vulnerable to different attack types. Is this correct ? BTW this is the kind of answers I was aiming at with my question. – SantiBailors Feb 07 '16 at 13:44
0

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.

RoraΖ
  • 12,317
  • 4
  • 51
  • 83
  • I agree that if I use "password" I'm to blame, although probably not much brute force will be used to crack that one so that's not a good example of the scenario I have in mind. However even though no user in the world is entitled to complain against the system if such a silly password gets guessed, so far I still don't see any reason to forgive a system that allows the kind of large scale login attempts I described. And when both things occur (silly password but guessed through large scale attempts) in my opinion the share of blame on the system cannot be less than 50%. – SantiBailors Feb 03 '16 at 14:53
  • I guess I'm not very clear on your question? Are you asking who's to blame if large scale login attempts are allowed? – RoraΖ Feb 03 '16 at 14:55
  • More or less; if those attacks are feasible at all, IMO the system alone is clearly to blame for that, because it's only up to the system to make them unfeasible regardless of their outcome. And since currently it appears to me that making those attacks unfeasible would be relatively trivial, what I'm trying to understand with my question is why don't the vast majority of systems make those attacks unfeasible. – SantiBailors Feb 03 '16 at 15:23
  • The huge numbers of guesses per second you see all over the place has nothing to do with a system that allows that many guesses per second. Usually that's an attack on a stolen database. In fairness, one could blame the system for the SQL injection or whatever gave up the password database in the first place...but it has nothing to do with login rules. Matthew's answer does a good job discussing the differences between online and offline attacks. – Ben Feb 03 '16 at 17:28
  • @Ben I'm not clear what your first sentence means. However I'm only thinking of online attacks, and what I'm trying to understand with my question is why systems don't make password-guessing attacks unfeasible by slowing down repeated login attempts with same username or IP or such. I will edit my question to better reflect that. – SantiBailors Feb 07 '16 at 13:42
  • 2
    @SantiBailors, the question is asking, after seeing comics, articles, etc. about choosing passwords that defend against "a gazillion" guesses per second, why any system would allow that. The answer is: they don't. Almost all those articles, questions, comics, etc. are giving advice to defend against offline attacks where the system constraints are irrelevant. – Ben Feb 07 '16 at 16:19
  • @Ben Thanks, apparently I needed it to be put in the way you just put it, in order for me to understand. So the answer is that the majority of systems do prevent - or try to prevent - too frequent online login attempts from the supposedly same source. So what I was missing big time is that avoiding weak passwords is not mainly intended to make it difficult to have the pw guessed in an online login attempt attack, but to make it difficult to have the pw guessed offline on a stolen db. If you could put this in an answer I'd mark it as the accepted answer. – SantiBailors Feb 08 '16 at 09:05
  • Thanks, but I think the current top answer is better, because it points out that defending against *both* types of attack is needed. So I'll refrain from answering for now. – Ben Feb 08 '16 at 12:54