Verify All Account Password Hashes are Shadowed
Ensures no real password hash is stored in the world-readable /etc/passwd; all hashes belong in /etc/shadow.
Checked against what is installed or registered, packages present/absent, account databases.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
Why this rule matters
Password hashes must live in /etc/shadow, which is readable only by root, and never in the world-readable /etc/passwd. The second field of every /etc/passwd entry should therefore be a placeholder (x, * or !). A real hash stored there exposes every user's credential to offline brute-force or dictionary cracking by any local account.
What Pavois checks
Pavois uses awk to list any /etc/passwd entry whose password field is not a placeholder (x, *, !). The check passes only when the list is empty. Inspecting the resolved account database directly is the only reliable way to confirm credentials were migrated to /etc/shadow and not left exposed.
describe command('awk -F: \'($2!="x" && $2!="*" && $2!="!"){print $1}\' /etc/passwd') do
its('stdout.strip') { should eq '' }
endHow to verify it is applied
Run awk -F: '($2!="x" && $2!="*" && $2!="!"){print $1}' /etc/passwd. Expected output: nothing. Any printed username has a non-shadowed password field that must be migrated with pwconv.
Inspect & investigate
- Confirm a clean migration:
pwck -rthen re-check/etc/passwd. - Compare entries:
getent passwd <name>vsgetent shadow <name>. - Authentication events:
/var/log/auth.log(Debian/Ubuntu) or/var/log/secure(RHEL family).
Remediation
No automated remediation is shipped. Fix it manually by running pwconv, which moves any inline password hashes from /etc/passwd into /etc/shadow and replaces them with the x placeholder, then re-run the scan to confirm.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | grep -E '^[^:]+:[^:!*x]' /etc/passwd # accounts with a hash still in /etc/passwd pwconv # migrate them to /etc/shadow |
|---|---|
| reason | moving passwords to /etc/shadow with pwconv is safe but verify no app reads /etc/passwd hashes |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
A password hash left in the world-readable /etc/passwd lets any local user copy it and crack it offline, leading to credential theft and privilege escalation. The fix (pwconv) is low-risk and standard, but back up /etc/passwd and /etc/shadow first and verify logins still work afterwards.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 7.2.1, 8.3.2 | direct | per OS, see the benchmark table | high |
| NIST | 3.5.10, CM-6(a), IA-5(h) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 8.3.2 | supporting | 4.0.1 | medium |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.