/etc/shadow line validator

The /etc/shadow file: why Linux split passwords from /etc/passwd

In early Unix systems, encrypted passwords lived together with public account metadata inside /etc/passwd. Because that file must be world-readable so commands such as ls, ps or id can translate UIDs into usernames, every local user could read every password hash and feed it to a cracker. The shadow suite, introduced in the 1990s and adopted as the Linux default, fixed the issue by moving the hash to /etc/shadow, owned by root:shadow and chmod 640. Only privileged processes (PAM, passwd, chpasswd, useradd) can read it.

This validator parses a single shadow line and tells you whether the format is well-formed: nine colon-separated fields, a recognized hash algorithm prefix, valid aging counters and proper lock markers. It runs entirely client-side — nothing is sent to a server and the hash never leaves your browser.

Line format: nine colon-separated fields

Each line follows the structure username:hash:lastchg:min:max:warn:inactive:expire:reserved:

• username: matches the entry in /etc/passwd.
• hash: encrypted password (see formats below), or !/* to lock the account, or empty to disable password login.
• lastchg: days since 1970-01-01 of the last password change.
• min: minimum days between password changes.
• max: maximum days a password is valid.
• warn: days of warning before expiration.
• inactive: days after expiration before the account is locked.
• expire: absolute expiration date (days since epoch).
• reserved: unused, kept for future extensions.

Hash algorithm prefixes

The leading $id$ identifies the hashing scheme. Modern crypt(5) supports:

• $1$salt$hash — MD5 crypt. Deprecated; fast on GPUs.
• $2a$cost$hash / $2b$ / $2y$ — bcrypt (Blowfish). Cost factor tunes work.
• $5$rounds=N$salt$hash — SHA-256 crypt (glibc).
• $6$rounds=N$salt$hash — SHA-512 crypt, default on CentOS/RHEL 7-9 and Debian 11.
• $y$rounds$salt$hash — yescrypt, the default on Ubuntu 22.04 LTS and newer.
• $argon2id$v=19$m=N,t=N,p=N$salt$hash — Argon2id, PHC winner (2015), memory-hard.
• ! or * alone — locked account, no login possible.
• empty field — password login disabled; key-based or PAM-only access.

Permissions, ownership and tooling

The canonical state is chown root:shadow /etc/shadow and chmod 640. Anything more permissive is a serious finding for any CIS or Lynis audit. Day-to-day management uses passwd (change own hash), chpasswd (bulk update via stdin), useradd/userdel, and chage for aging policy (chage -M 90 alice forces rotation every 90 days). Ansible's user module and Puppet's user resource manipulate shadow safely on fleets of servers.

Cryptographic guidance: NIST 800-63B and migration

NIST SP 800-63B recommends memory-hard KDFs (Argon2, scrypt, yescrypt) and explicitly discourages legacy MD5 and unsalted SHA. If your fleet still emits $1$ or $5$ hashes in 2025, plan a migration path: switch ENCRYPT_METHOD in /etc/login.defs to YESCRYPT or SHA512, then force a rotation. PCI-DSS v4 requirement 8.3.2 likewise mandates strong one-way hashing for stored authenticators.

Offline cracking and backup hygiene

If /etc/shadow leaks (misconfigured backup, compromised image, careless tar of root), attackers run John the Ripper (john --format=sha512crypt) or Hashcat (modes 1800, 7400, 7500) offline. The whole defense rests on the hash strength: bcrypt with cost 12 or Argon2id with m=64 MB pushes cracking into the economically infeasible range, while MD5 falls in minutes on a single RTX 4090. Always encrypt shadow backups (LUKS, age, GPG) and never copy them off the host in cleartext.

FAQ

Is yescrypt safe for production? Yes. It is the Ubuntu 22.04+ default, memory-hard, and accepted by NIST guidance equivalents. It outperforms SHA-512 crypt on the same hardware budget.

Can a regex really validate a shadow entry? Only the syntax. The validator confirms field count, hash prefix and numeric aging columns. It cannot prove the hash matches a password — that requires running the KDF against a candidate.

Does this tool store what I paste? Never. Parsing runs entirely in your browser. No request is fired and no log is written. Do not paste production hashes into random websites — local tools or your terminal are safer.

What does the ! prefix mean? A lone ! or * locks the account: PAM rejects any password. A ! prepended to a valid hash (e.g. !$6$...) is a "soft lock" used by usermod -L — the original hash is preserved and can be restored with usermod -U.

Why is MD5 ($1$) still an anti-pattern in 2025? A modern GPU computes billions of MD5 hashes per second. Any password under 12 random characters falls quickly. Even with salt, MD5 offers no work factor and no memory hardness. Migrate to yescrypt or Argon2id.