sha512crypt and /etc/shadow: how Linux stores your password

Open /etc/shadow on any Linux box and you are looking at the last line of defense for every local account. It is the file an attacker wants after a foothold, because everything they need to crack passwords offline is sitting in one place. Understanding what each field means is the difference between knowing you have a 5000-round sha512crypt hash you can throw at a GPU and not knowing what you are looking at.

The shadow line, field by field

Each entry is colon-delimited and looks like this:

root:$6$xQ9Hk2pL$Hf3...truncated...0:19876:0:99999:7:::

The first field is the username. The second is the password hash, and that is the part that matters. The rest are aging metadata: days since the last password change, minimum and maximum age, the warning period, and an inactivity window. None of that protects the hash. If the attacker can read the field, the clock fields are irrelevant.

The hash field itself is structured. It is not one opaque blob, it is $id$rounds$salt$digest, dollar-delimited, and you can read it left to right.

The $6$ tells you the algorithm

The id between the first pair of dollar signs is the scheme. $6$ is sha512crypt, which is what nearly every mainstream distro has defaulted to for the last decade. You will still find $1$ in the wild, which is md5crypt, the old default that should have died years ago. $5$ is sha256crypt, a rarely used middle child. $2a$ or $2b$ is bcrypt. $y$ is yescrypt, which is where the modern distros are heading.

So before you do anything, read the prefix. A $6$ hash is mode 1800 in hashcat. A $1$ hash is mode 500. Getting this wrong wastes a run.

Rounds, and the default that everyone forgets to raise

sha512crypt is not a single SHA-512 call. It is a deliberately slow construction that runs the underlying hash thousands of times. The iteration count is the rounds= parameter, and if you do not see it, the default applies.

That default is 5000 rounds. When the field reads $6$rounds=100000$salt$digest, someone bumped it on purpose. The vast majority of shadow files you encounter use the silent 5000, because almost nobody touches the crypt configuration. You can raise it in /etc/login.defs with SHA_CRYPT_MIN_ROUNDS, and on a slow-hash scheme like this, raising rounds is the single cheapest defensive win available. It does nothing for a weak password, but it linearly increases the attacker's cost per guess.

The salt does its job, then stops

Every sha512crypt hash carries a per-entry salt, the chunk between the rounds and the digest. It does exactly what salt is supposed to do: it kills rainbow tables and guarantees two users with the same password get different hashes. What it does not do is slow down a single guess. Salt defeats precomputation, not throughput. That distinction is the whole reason rounds exist.

Slower than raw SHA-512, weaker than bcrypt

Here is the honest positioning. sha512crypt is far better than handing someone a bare SHA-512 of the password, because 5000 iterations turn a billion-guess-per-second algorithm into something measured in the low millions or less. But it has a structural weakness that bcrypt and argon2id do not: it is not memory-hard. It fits comfortably in a GPU's registers, so an attacker parallelizes it across thousands of cores cheaply. bcrypt was designed to be cache-unfriendly, and that is exactly why bcrypt resists GPUs in a way sha512crypt never will. Argon2id goes further and demands real memory per guess. sha512crypt sits in the middle: not fast, not hard.

This is why modern distros are migrating to yescrypt by default. It is memory-hard, it is the new $y$ prefix, and it closes the GPU gap that sha512crypt leaves open.

Cracking it: unshadow and mode 1800

For John the Ripper, you merge /etc/passwd and /etc/shadow first, because John wants both:

unshadow /etc/passwd /etc/shadow > hashes.txt
john --wordlist=rockyou.txt hashes.txt

For hashcat you do not need unshadow. Strip the hash field out of the shadow line, drop it in a file, and run mode 1800:

hashcat -m 1800 -a 0 hashes.txt rockyou.txt -r /usr/share/hashcat/rules/best64.rule

Now the throughput reality. On a single modern GPU you are looking at a few thousand to low tens of thousands of guesses per second against 5000-round sha512crypt. That is glacial compared to the billions per second you get on MD5. A 14-million-word list with a heavy rule set will not finish in your lifetime here. The strategy has to change: small, curated, targeted lists with a light rule set, exactly as covered in the wordlist and rules guide. Throw the kitchen sink at a fast hash. Throw a scalpel at this one.

The defender's takeaway

If you administer Linux systems, two things move the needle and neither is exotic. Push password length, because length beats every rule set and mask an attacker owns. And use a modern scheme: prefer yescrypt where your distro offers it, raise sha512crypt rounds well above 5000 if you are staying on it, and never let $1$ md5crypt survive a migration. The hash in the shadow file is only as strong as the password behind it and the algorithm wrapped around it.