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:
How does having password hash make cracking easier? Are my guesses above correct or did I get something wrong / miss some ways?
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
johnon a Linux system. I started looking into
hashcattoo but didn't know what dictionaries I should use.
johnseemed 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
johnthe 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.
IIRC most Linux distros use sha512 for their
/etc/shadowhashes. 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.
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...