0

On Windows, user password hashes are not salted and, on Linux, user password hashes are stored in the same root-owned file as the salt. Given this, in what ways might a bruteforce attack to find the user's password using the known hash potentially be more efficient/faster/more successful than an similar bruteforce attack without a known password?

To give a bit of context about why I would ask this: I have recently been reading about how Linux has traditionally managed passwords in /etc/shadow and about a newer model implemented in systemd-homed's LUKS container file. I became curious about this storage configuration, why the password hash seems so easy for an attacker using a livedisc to get, how easy would it be to crack once they have it, and possible ways to harden the system security against this. But those questions belong in another post I think.

Looking to see if I correctly understand how having a hash allows password crackers to bruteforce things more easily. This is mostly for my own academic understanding. I've been try to improve my own systems security lately and it's something I keep finding myself wondering about and wanting to understand how it works on "the other side". I know this attack is dependent on a few things, so I will limit the context to an attacker with physical/on-site access who wants to know the user's password. I also realize this is probably not the most likely real-world attack scenario... as there are easier / more useful things to go after. Anyway, since I've seen a few examples use Alice and Bob, I'll use "Craig the cracker" below.

My understanding so far is that if "Craig" has a password hash, he might have a slightly easier time brute-forcing a password (than if he had no password hash to go on). But not sure I completely get why.

I've been thinking about this and what I've come up with so far is:

  • If Craig had time and storage to prepare beforehand (or maybe downloaded one?), he could have pre-generated a list of hashes:passwords based off a dictionary. If he then gets a password hash, he could simply look it up. If the hash appears, it is "game over" for the user's security. If it does not, then he can still save time by skipping that dictionary entirely and moving on to to whatever the next step would have been. Not sure if rainbow tables are the same thing or if that's something different; I've never really had a good grasp of what those were.

  • If Craig didn't have the hash, I assume he would limited by the speed of whatever he is trying to break into. For an OS login, this perhaps be difficult to test each "guess" especially if it couldn't be done without a remote terminal such as SSH. But if we were talking about an encrypted drive that he knows they use the same password for, then pulling the drive and putting it into Craig's pc, he'd still be limited by I/O speed of the drive even if everything else involved in trying a new guess was faster. Versus trying to solve "which value produces this hash" which can be done entirely in RAM/CPU/GPU without going out to the disk. So if he has a known password hash, I think he would gain some increases to the number of guesses/minute.

So my actual questions are:

  1. How does having password hash make cracking easier? Are my guesses above correct or did I get something wrong / miss some ways?

  2. Do crackers actually use pre-generated hash tables for things in practice? If these are different than rainbow tables, what is the difference and is there a correct term for these? Sorry... My experience is limited to trying to bruteforce my own passwords using john on a Linux system. I started looking into hashcat too but didn't know what dictionaries I should use. john seemed to nearly instantly find very common passwords that are probably leaked on haveibeenpwned ("test", "abcd", etc) but seemed to choke up on a simple 5-digit numerical garage door code I don't use anymore; I made a dummy user with this password, gave john the hash, and let it go... 3-days later when I needed to reboot my home server, it still hadn't found it so I cancelled. This was with 100% default settings obviously.

  3. IIRC most Linux distros use sha512 for their /etc/shadow hashes. Don't know if I can actually change which hash algorithm it uses but assuming I could, would using a less common but still secure one be of any benefit? If so, are there any options that have comparable security to sha512? The only non-sha one I know of is whirlpool. But my thinking here is just that if Craig has gone through all the trouble to prepare a hash table using sha512 and mine isn't sha512, then he needs to start at the beginning or at least I'm not making it easy for him.

  4. If the HDD (unknown hash) vs RAM/CPU/GPU (known hash) thing does make a huge difference, can somebody try to roughly quantity what sort of difference it would be? Assume the password is of moderate strength and not leaked and that Craig is using nothing more than a decent consumer-grade gaming rig. I'm not looking for exact numbers, just looking for a (very) rough idea how much easier having the hash might make things (e.g. is it 1/2 the time? 1/4? 1/8? only shaving a couple days off a theoretical 500 year?) I currently have no way to conceptualize the difference at all...

zpangwin
  • 321
  • 2
  • 9
  • 2
    I think your question misses a "speed up __compared to what__". For example when the alternative is to brute force a remote login than it is for once slower because of network latency but then the side might also employ heuristics to detect brute force attempts and deliberately slow them down. When having a local password hash the speed solely depends on how fast one can locally compute. – Steffen Ullrich Jun 28 '21 at 20:13
  • A single server checking passwords will most likely not have the same password-checking capability as a dedicated, multi-GPU cracking machine. That's not even taking into account the points that @SteffenUllrich brought up. – user Jun 28 '21 at 20:45
  • @user ok, that's fine. I understand that it will be different for remote stuff like Steffen said and that high-end equipment like cryptominer rigs would be faster than normal consumer pcs. I was mostly trying to understand how much having a known password hash speeds up bruteforcing vs bruteforcing without knowing the password hash. Steffen's comment made it sound like there was something in how I asked my question that was not clear and I was just trying to see if I needed to correct that. I thought I was actually asking for a pretty specific use-case if anything but maybe it is not good? – zpangwin Jun 28 '21 at 20:55
  • "If Craig didn't have the hash, he would have to access the HDD/SDD directly to try each guess" -- huh? What type of system would this be relevant for? – schroeder Jun 28 '21 at 21:01
  • @schroeder thank you for exactly highlighting a problem spot. I will address. short version: my understanding based on various readings online that make it sound like bruteforcing with a password hash is somehow easier than without. I don't know anything about cracking, hence why I am trying to ask if this is correct and if so, how does it work. As for easier *than what*, I mean is it easier with a hash than without one. – zpangwin Jun 28 '21 at 21:02
  • @schroeder ""If Craig didn't have the hash, he would have to access the HDD/SDD directly to try each guess" -- huh? What type of system would this be relevant for?" Originally, I had also been thinking in terms of LUKS / FDE. I can see where this needs revision after I limited my example. I will fix. For the part about salts in your next comment, I am not from a security background. Are salts used universally for all password hashes? It sounds like I may need to go back and confirm whether salts are used in the hashes for the things I am interested in (e.g. Linux /etc/shadow, LUKS, etc) – zpangwin Jun 28 '21 at 21:10
  • "without a known password?" -- did you mean, "without a known hash?" And is the context of your question about OS and FDE passwords? – schroeder Jun 29 '21 at 06:50
  • I don't understand your question You're asking if brute forcing hashes is faster. Faster than what? Typing in passwords at a login screen? It seems patently obvious that it is. Your question is long and rambling and needs more focus. – Blake Jun 29 '21 at 15:27
  • @Blake: For example, on traditional Linux/Windows setups the user's password hash can be obtained via a livedisc. In a Linux system-homed setup, the hash is stored in an encrypted LUKS container. If an attacker wanted to bruteforce the user password, then in the first scenario he would have a hash. But not in the homed scenario. Trying to understand how having the hash might give the cracker any sort of advantage (e.g. being faster) over not having one. I have tried multiple times to fix my question... all I can say at this point, is if it's still bad, please vote to close it. I don't mind – zpangwin Jun 30 '21 at 16:44

2 Answers2

4

What you are describing is the difference between "online" and "offline" brute-forcing.

Yes, having a hash and performing an offline brute force will allow you to be more resource-efficient and brute-force the hash in parallel without any technical limitations imposed by the authentication system. So, sure, it's "easier". Being "onsite" and performing an offline bruteforce offers you nothing.

An online brute force requires you to interact with the system and all of its protections. This is, by its very nature, slower, even if you can bypass security controls. You need to interact with the system.

This understanding defeats your questions 1 & 4.

Salts

Pre-generated hash tables/rainbow tables are not used anymore since password hashing is supposed to be done with a salt. Salts defeat rainbow tables. Salts require you to test each hash fresh.

This fact defeats your questions 2 & 3.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • Yeah, I think salts was a big part of what I was missing. So on Linux, even though they print the salt in the same file as the password hash, it sounds like merely by using the salt it still prevents crackers from being able to use pre-generated rainbow tables for non-salted hashes. And since the salt would presumably be unique per-user, there is no way the attacker could have a pre-computed it without a *massive* amount of effort to pre-compute every possible salt. which is not practical to do with current technology. So the only avenue of attack left would be to go back to regular bruteforce – zpangwin Jun 29 '21 at 01:56
  • So does having a password hash that is salted offer *any* advantage whatsoever to an attacker over not knowning the hash at all? (asking bc it seems related but if this needs to be asked as a separate question please let me know) – zpangwin Jun 29 '21 at 02:03
  • Again, what does it mean to "not have the hash at all?" If you are talking about an online brute force of a password, I have answered that. – schroeder Jun 29 '21 at 06:47
  • "what does it mean to "not have the hash at all?"" : For example, say trying to do an offline bruteforce of a Linux systemd-homed setup that is using a LUKS container. In this configuration, almost everything about attacking the local user account is identical *except* that password hash now lives within the encrypted container itself and is not visible to the attacker as it would be under a traditional Linux/Windows setup using a livedisc/etc. That was the main element of my original question that I still don't understand: e.g. does having access to the password hash make cracking easier/etc? – zpangwin Jun 30 '21 at 16:04
  • That's not an "offline" bruteforce, then. You are bruteforcing the system that is online. You are interacting with the system to test the credentials. – schroeder Jun 30 '21 at 16:13
3

Your question is rather long and not really "a single question", so I'll take a step back.

Let's separate things into three categories, I'll give them names:

  1. Passwords in plaintext: Craig gets into the local system and gets access to a db of user passwords in plaintext.
  2. Password hashes: Craig gets into the local system and gets access to a db of user password hashes.
  3. Login or decryption oracle: Craig has access to some software, such as a login page for a web app, encrypted USB thumb drive, device boot screen, etc, where Craig can try guessing passwords until he gets it right.

For 1) Passwords in plaintext; we're done, Craig has the password. Game over.

For 2) Password hashes; Craig has to crack the hash. This is better than plaintext passwords. Everything you mention above applies: pre-computed password:hash dictionaries or rainbow tables, GPU-accelerated cracking, etc. There are also lots of defensive best practices for how to generate password hashes: salts, peppers, hash functions with large time or memory work factors, etc. Hash generation and cracking is a whole field unto itself and will not fit in this answer.

For 3) Login or decryption oracle; Craig can still crack, but he has to interact with some software, which means the software can enforce rate-limits (number of guesses per second), account lockouts, even wiping the device after a number of incorrect guesses. There is a whole field of what's called "side-channel attacks" to circumvent this (depending how the device works), such as soldering wires onto the debug pins of the mother board, ripping the RAM sticks out of the device while it's running to read memory off them, etc. But this is still harder for Craig than cracking hashes.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • "Your question is rather long and not really 'a single question'"... yes, sorry about that. I have tried to revise to hopefully be helpful to someone else in the future. Wanted to say thanks for anwsering though. Even though you answered something slightly different than what I was trying to ask (entirely my fault for the poorly formed question), you still ended up introducing me to some new terms so I upvoted – zpangwin Jun 29 '21 at 02:21