How does /etc/shadow work?

How /etc/shadow fits into Linux local authentication

/etc/shadow is the protected companion to /etc/passwd for local Linux accounts. The key design choice is separation: account metadata stays broadly readable, while password hashes and password ageing fields are kept behind tighter file permissions. That lets the system validate a login without exposing the secret material to ordinary users or most processes.

In practice, /etc/shadow is part of the local authentication path, not a user-facing account list. The login stack reads the stored hash, compares it to the password-derived hash from the user prompt, and then applies the ageing policy fields to decide whether the password is valid, expired, or due for change. Because it is local system state, correct ownership and mode bits matter as much as the contents themselves.

One useful way to think about it is that /etc/passwd tells the system who the local account is, while /etc/shadow holds the sensitive authentication material and policy timers that should not be broadly exposed. That division is why defenders should treat a readable shadow file as a serious misconfiguration, even if the hashes are not immediately crackable.

What is stored in /etc/shadow and why it is separate

The file typically contains one entry per local account, with the username, the password hash field, and ageing data such as last change date, minimum and maximum password age, warning period, inactivity period, and account expiry. Empty or locked fields can indicate disabled logins, service accounts, or accounts that are intentionally not meant for interactive use.

The separation from /etc/passwd is a confidentiality control. Historically, password hashes lived in /etc/passwd, which meant every local user could read them. Modern Linux systems moved the hash into /etc/shadow so only privileged processes can inspect it. That reduces offline attack opportunities and limits the blast radius if a low-privilege account is compromised.

On Linux, the shadow file is not just about secrecy. Its ageing fields support operational policy enforcement, such as forcing a password change after a defined period or warning before expiry. That makes it both an authentication store and a simple lifecycle control point for local accounts.

What can go wrong if /etc/shadow is exposed or stale

If permissions are too open, an attacker or untrusted local user can copy the hashes and attempt offline cracking. Even when the hashes resist immediate recovery, exposure still increases risk because it creates a reusable authentication target and may reveal weak or reused passwords. If old accounts remain present, the file can also preserve dormant access paths long after the business need has ended.

The ageing fields can fail in quieter ways. Weak password lifecycle settings may allow credentials to remain valid for too long, while missing expiry or inactive-account handling can leave abandoned accounts available for abuse. On multi-user systems, that turns a routine local file into a durable trust anchor that attackers may target after they obtain any foothold.

The operational problem is not limited to cracking. A compromised local account with access to the shadow file can accelerate lateral movement, password reuse discovery, and privilege escalation attempts. For that reason, reviewers should think about exposure, not just readability, and verify that shadow contents are tightly controlled and that obsolete identities are removed or locked.

Practitioner Guidance

What to verify: Confirm that /etc/shadow is owned by root, not group- or world-readable, and that only the intended account management tools can write to it. Also check that password ageing fields reflect the organisation’s policy rather than default or accidental values.

What to prioritise: Treat unexpected readability, permissive backups, and stale local accounts as higher priority than cosmetic hardening. A readable shadow file with active hashes is an exposure issue, while an obsolete locked account is usually a hygiene issue unless it can still be re-enabled or abused.

Decision rule: If an account is no longer needed, remove it or lock it rather than relying only on a long password age. If the hash has been exposed, plan for password rotation and broader compromise review, because the risk is offline extraction, not just interactive login.

What practitioners underestimate: /etc/shadow is often treated as a static system file, but it is really an access-control boundary. Its value comes from both secrecy and lifecycle hygiene, so file permissions and account cleanup need to be reviewed together.

Practitioner takeaway: The security of /etc/shadow depends on keeping password material unreadable, keeping ageing policy intentional, and eliminating accounts that should no longer exist.

Related resources from NHI Mgmt Group

• How does device fingerprinting work?
• How does integrated risk management work?
• How does IRAP work?
• How does Watermarking (AI Content) work?