3

In this question: Why is there a delay when entering a wrong password? it appears that there is a 1-2 seconds timeout in sudo once it is given a wrong password in order to make cracking attempts more difficult.

This is annoying for many users, and is it really a solution to the problem?

What prevents an attacker from running thousands of sudo instances in parallel and testing thousands of different passwords per second? The timeout doesn't prevent this.

2

3 Answers 3

3

Get your password correct first time?

Curiously I thought to test your claim that the delay wouldn't stop a brute. It seems silly that it could allow this... But here I am executing 2000 separate threads at once. It works.

parallel -j2000 sh -c 'echo $"{}\n" | sudo -S echo; echo done' -- {1..2000}

That litters auth.log with failures but it never pears above "2 incorrect password attempts".

I believed that PAM was supposed to stop people. Hence the delay.
This might be by [poor] design or it might just be a [quite serious] bug.

I have a system with a weak password on the network. I'm tempted to try this method to see it it can really scale up to brute-force the password.

5
  • I am on the "quite serious bug"-team :+
    – Rinzwind
    Feb 20, 2016 at 12:50
  • 1 thing: you are using parallel locally. That should be done remotely. ssh will have that delay.
    – Rinzwind
    Feb 20, 2016 at 13:30
  • @Rinzwind Maybe for SSH login, but I can still brute-attack sudo in parallel without delay. No denial that remote is worse but this is to get root via the account. Still fairly serious.
    – Oli
    Feb 20, 2016 at 16:24
  • To be accurate, if you can brute-force the account via sudo, you get what that user is allowed to do via sudo, which is not /always/ or even necessarily full root privileges. Again: defense in depth.
    – user459652
    Feb 21, 2016 at 14:17
  • Many people mention parallelism to get around it, but this is the first post I see where it's actually demonstrated. Upvoted for that.
    – Luc
    Apr 18, 2017 at 13:46
2

The delay isn't just about making brute-force attacks harder. It's also about information leakage. There was a famous SunOS exploit years ago that depended on knowing a password was wrong by seeing how quickly commands returned.

Security attacks often don't rely on a single vector, but combine vectors in interesting ways to leverage small bugs or oversights.

Hiding good vs. bad attempts from attackers you reduce the overall attack surface. It's the right thing to do.

If you don't like it, there are other authentication methods you can use.

4
  • "knowing a password was wrong by seeing how quickly commands returned" Well since it returns immediately when it's correct, I don't think the slowdelay added anything. It's a static timeout (/etc/pam.d/login) and not a constant-time comparison thing. "If you don't like it, there are other authentication methods you can use." That's like saying that if you don't like trains, rather than discussing issues and improving them, you can just take a bus or airplane.
    – Luc
    Apr 18, 2017 at 13:45
  • I fail to see your point. A successful login is not an attack vector. Multiple brute-force attacks are, and one of the attacks was a timing attack. Like I said, it was a known vector that partially correct passwords would return in varying amounts of time proportional to how correct they were. Putting in a fixed or obfuscated delay, perhaps with a longer delay after a number of failures, is just good practice. Other auth methods are not open to these attacks.
    – user459652
    Apr 18, 2017 at 14:26
  • "Like I said, partially correct passwords would return in varying amounts of time" no, you said: 'knowing a password was wrong by seeing how quickly commands returned'. But I figured this must be what you meant, and I still think it's incorrect: there is a fixed delay= in /etc/pam.d/login set to 3e6µs by default, not a variable one depending on how long the operation took. Constant-time comparison is something one fixes in code, not in a setting (e.g. redd.it/49hwq0). Brute-forcing is of course a thing, but this delay measure is nullified by spawning parallel logins.
    – Luc
    Apr 19, 2017 at 5:17
  • This isn't really relevant to the discussion at hand (so I have no idea why you are so fixated on it) but the SunOS attack used timing information to lower the cost of brute force attacks because the timings leaked information about the failed password (or hash). That's it. So, an easy fix is to have failed attempts return in a fixed amount of time. Since my whole answer is really about security often being tradeoffs that try to minimize the overall attack surface, this was merely a single example of how such attacks might be mitigated in the past.
    – user459652
    Apr 19, 2017 at 18:02
1

How do you see this happening "in parallel"?

With an 8 char password you have (26+26+10+12=) 74^8 possible words. Makes for 899.194.740.203.776 unique words. With a 3 second delay (it is 3 ;-) ) that makes 85.539.834 years (899.194.740.203.776 * 3 / (365*24*60*60)). Lets assume you need half the attempts so that would be 42.769.917 years. Even with 100000 (impossible I know) attempts in parallel it would (in average) take roughly 427 years.

A system that needs protection (for instance a user account database) will have a good password set (so the 8 chars might be even more) and also have a mail system set up to alarm an admin that someone is failing the password a lot.

Still believe it is possible?

4
  • 1
    (See my answer for the "how in parallel" it works scarily effectively but I'm not sure if it'll scale yet)
    – Oli
    Feb 20, 2016 at 12:45
  • Hmmm. That would lower the time by a factor 3. Still 142 years but that is getting more realistic to succeed than I would like.
    – Rinzwind
    Feb 20, 2016 at 12:48
  • Also you assume worst case scenario. The attacker would probably try passwords from a list. The point is that it is 100% possible to bruteforce it and the timeout isn't that helpful.
    – hytromo
    Feb 20, 2016 at 13:29
  • Password should be considered random chars and not dictonairy words. All systems (about 40 or so) that I know the sudo or root password for have random letters (of at least 8 chars).
    – Rinzwind
    Feb 20, 2016 at 13:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .