Prevent Login to Accounts With Empty Password
Ensures no account in /etc/shadow has an empty password field.
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
An account with an empty password hash in /etc/shadow can be logged into with no credentials at all. Anyone with network or console access can take over that account and run commands with its privileges, and if it is a privileged or service account, the whole system. Empty passwords must never exist in operational environments.
What Pavois checks
Pavois uses awk to list any /etc/shadow entry whose second field (the password hash) is empty. The check passes only when the list is empty. Reading the effective shadow database is authoritative: it reflects the actual stored credential state, not what a PAM policy is merely supposed to enforce.
describe command('awk -F: \'($2==""){print $1}\' /etc/shadow') do
its('stdout.strip') { should eq '' }
endHow to verify it is applied
Run awk -F: '($2==""){print $1}' /etc/shadow. Expected output: nothing. Any printed username is an account that can be entered with no password and must be locked or given a password.
Inspect & investigate
- List empty-password accounts:
awk -F: '($2==""){print $1}' /etc/shadow. - Confirm lock state:
passwd -S <user>(look forL/LK). - Successful logins (a flag if they used an empty password):
/var/log/auth.logor/var/log/secure.
Remediation
No automated remediation is shipped, because the right action depends on the account. Fix it manually: lock the account with passwd -l <user> (or usermod -L <user>) if it should not log in, or set a strong password with passwd <user>, then re-run the scan.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | awk -F: '($2==""){print $1}' /etc/shadow # accounts with NO password # passwd -l <user> (lock) for each, after confirming it should not log in |
|---|---|
| reason | locking an account is disruptive, confirm each empty-password account before locking |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
An empty password is an immediate, no-credential entry point, one of the highest-impact account flaws (full takeover of the account, often the system). Before locking an account, confirm it is not relied upon by an automated process that authenticates without a password; locking the wrong account can break services or remove your own access.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 8.3.1, 5.3.3.4.1, 7.2.2 | direct | per OS, see the benchmark table | high |
| NIST | 3.1.1, CM-6(a), IA-5(1)(a), IA-5(c) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 2.2.2, 8.3.1 | supporting | 4.0.1 | medium |
| DISA STIG | UBTU-22-611060, UBTU-22-611065, UBTU-24-300028, UBTU-24-300027 | direct | per OS STIG release | high |
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.