Store /etc/shadow with strict root-only access, because it contains password hashes and account ageing data. It should not be world-readable, and only privileged administrative tools should access it. Defenders should verify file ownership and permissions, monitor for unauthorised reads, and use strong password hashing and account controls.
How /etc/shadow should be stored and protected
/etc/shadow should be treated as a sensitive credential store, not a normal configuration file. Its protection goal is simple: preserve confidentiality, prevent tampering, and ensure only trusted administrative processes can read it. If the file is readable by non-privileged users, the system has already weakened password secrecy and account security.
The practical baseline is strict ownership, restrictive permissions, and controlled access paths. On Unix-like systems that usually means root ownership, a mode that blocks world access, and only narrowly approved utilities reading it. The important point is not just the file mode itself, but that no secondary path, backup, export, or script leaves the same data easier to read than the live file.
Because /etc/shadow holds password hashes and ageing data, defenders should also protect the surrounding operating model. That includes monitoring for unexpected reads, reviewing administrative tooling that touches authentication files, and ensuring password hashing remains strong enough to resist offline cracking if the file is exposed. If the local account database is replicated or copied elsewhere, the same controls must follow the copy.
What can go wrong if /etc/shadow is exposed
The main failure mode is offline password attack. Once an attacker or untrusted user can read the file, they can copy the hashes and test guesses without touching the live system again. Even when passwords are not immediately recovered, ageing metadata and account state can help an attacker prioritise targets and understand which accounts are active or stale.
Exposure also broadens the blast radius of other local weaknesses. A misconfigured backup, an over-permissive support script, or an administrator using an unsafe workflow can turn a single file access issue into credential compromise. For that reason, treating /etc/shadow as “just another file” is a common control failure, because the file is only safe while its access boundary stays intact.
Failure mechanism: weak permissions, inherited group access, unsafe backup handling, or privileged tooling mistakes expose hashes to non-authorised readers, who then move to offline cracking or account targeting.
Impact: password compromise can lead to account takeover, privilege escalation, lateral movement, and persistence through any account that reuses the same secret or has excessive privileges.
How to verify the file is actually protected
Verification should be evidence-based, not assumed. Check ownership and permission bits on the live file, then confirm the same restrictions apply to any backup, image, container layer, configuration management artifact, or forensic export that may contain the same data. If a system is hardened but its backup set is not, the protection is incomplete.
It is also worth testing the access path, not just the metadata. Confirm that ordinary users cannot read the file, that administrative access is mediated by approved tooling, and that audit data exists for suspicious reads or permission changes. If you only check the file once during hardening, you miss drift caused by automation, package updates, or emergency admin work.
For deeper context on password-hash exposure and the value of defensive monitoring, see Credential Dumping Guide, which covers how attackers extract and abuse stored credential material. For baseline file and access-control discipline, the NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful control reference, especially where access control, auditability, and configuration management intersect.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Restricts who can read sensitive authentication files. |
| AU-2 — Event Logging | Auditing supports detection of unauthorized shadow-file reads or changes. | |
| Recommendation — Limit file access and administrative reads to the minimum set of trusted processes. Log access to authentication files and review anomalous read events. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Directly governs restricting access to sensitive system files and credentials. |
| Recommendation — Apply access control rules that keep shadow data available only to authorized administrators. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Covers controlling and reviewing access to sensitive local account data. |
| Recommendation — Enforce and review access rights for files that store credential material. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Shadow files expose credential material if permissions or copies are weak. |
| Recommendation — Prevent secret leakage by restricting reads and hardening all copies of credential stores. | ||
Practitioner Guidance
What to verify: Validate the file mode, ownership, and access chain together. A correct mode on the live file is not enough if backups, exports, or configuration tools can still expose the same hashes to non-root users.
Decision rule: If the file can be read outside tightly controlled administrative execution, treat that as a credential exposure problem, not a housekeeping issue. Prioritise fixing the read path and reviewing account exposure before assuming the system is otherwise safe.
What practitioners underestimate: The real risk is often not the local file alone, but the ecosystem around it, backups, images, scripts, support workflows, and audit gaps. Those secondary paths are where restrictive Unix permissions are most often undone in practice.
Practitioner takeaway: /etc/shadow is safe only when its secrecy survives every path that can copy or read it, so protection has to cover permissions, tooling, backups, and monitoring together.