Limit Password Reuse: password-auth
Requires a password history depth of at least 24 (remember>=24) so users cannot cycle back to any of their last 24 passwords.
Checked against the content of a persistent configuration file, the source of truth that survives reboots.
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
Preventing reuse of previous passwords helps ensure that a compromised password is not reinstated by a user. A deep history (24) makes it impractical to bounce back to a familiar password after a forced change, so periodic expiry actually forces genuinely new secrets rather than a short rotation through a few favorites.
What Pavois checks
Pavois reads the effective value by scanning both /etc/pam.d/ and /etc/security/pwhistory.conf for every remember=N, taking the highest N and requiring it to be at least 24. Looking at the resolved configuration (PAM line option and the pwhistory.conf default together) matches what the system actually enforces, a single file might show a weaker value that is in fact overridden, or vice versa.
describe command('v=$(grep -RhoE \'remember[[:space:]]*=[[:space:]]*[0-9]+\' /etc/pam.d/ /etc/security/pwhistory.conf 2>/dev/null | grep -oE \'[0-9]+\' | sort -n | tail -1); { [ -n "$v" ] && [ "$v" -ge 24 ] && echo ok; } || echo ko') do
its('stdout.strip') { should eq 'ok' }
endHow to verify it is applied
Run grep -rhoE 'remember=[0-9]+' /etc/pam.d/ /etc/security/pwhistory.conf and confirm the effective (highest) value is >= 24. Functionally, after changing a password, attempts to set any of the last 24 should be rejected.
Inspect & investigate
Reuse rejections are logged in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/Fedora). The retained hashes are stored in /etc/security/opasswd.
Remediation
No automated remediation is wired for this rule, so it must be applied manually: set remember=24 on the pam_pwhistory.so (or pam_unix.so) line in the password stack, or set remember = 24 in /etc/security/pwhistory.conf, then regenerate PAM (pam-auth-update / authselect).
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | # Enforce password history via pam_pwhistory. Set in /etc/security/pwhistory.conf: remember = 5 # and ensure pam_pwhistory is enabled: pam-auth-update --enable pwhistory |
|---|---|
| reason | password-history policy choice, set the depth deliberately |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Increasing history depth only affects password changes and cannot lock out an active session. The practical caveat is that the new depth applies going forward as /etc/security/opasswd fills up, and users with weak password habits may need a few resets to find a fresh value. Precautions: keep a root session open while editing PAM, and verify passwd still works on a test account before enforcing widely.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 5.3.3.3.1 | direct | per OS, see the benchmark table | high |
| NIST | 3.5.8 | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 8.3.7 | 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.