Password Reuse, Refused By A Host That Remembers

pam-pwhistory

An EL host does not remember passwords, so one can be put straight back. pam_pwhistory is not in the authentication stack, /etc/security/pwhistory.conf ships with nothing active in it, and /etc/security/opasswd - where the history would live - is an empty file. Measured: three changes, A to B and back to A, all accepted, with opasswd still zero bytes afterwards. This role writes the policy, puts the module into the stack through authselect, and proves the refusal by attempting the reuse.

No download, and no version to pin. pam and authselect are EL 10 packages. What the role owns is pwhistory.conf, the mode of the history file, and one authselect feature - and what it proves is that a password the host has already seen is refused, for that reason.

enforce_for_root is not about root's password. It is about who is making the change. The check is skipped whenever the calling process is root - so with this option off, an administrator resetting somebody else's password bypasses the history entirely, which is how most passwords are reset. The mutation matrix is what established that: turning the option off was expected to affect only root's own account and instead let an ordinary account's reuse through, because the test makes its changes as root. Root's own reuse is the smaller half of the same fact: without the option it prints "Password has been already used" and then reports "authentication token altered successfully".

chpasswd run as root bypasses the history entirely. Measured: with this policy in force and the password in the history, echo user:password | chpasswd succeeded and the account then authenticated with it. chpasswd writes /etc/shadow and never asks PAM, so the live test drives pamtester instead - the same lesson the password-quality role in this catalogue paid for.

The file is what turns the control on, not just what tunes it. With pwhistory.conf left exactly as the distribution ships it - every line a comment

• a reuse was accepted even with the module in the authentication stack. So both halves of this role are load-bearing: the authselect feature that puts pam_pwhistory in the stack, and the policy file that gives it something to enforce. Measured by pointing the role's file elsewhere and watching the refusal disappear.

Nothing validates pwhistory.conf, and a bad value fails OPEN. With remember = notanumber the module printed its complaint and the change went through. remember = 0 disables the check outright, which was measured with two identical changes in a row, both accepted. So the test attempts a reuse rather than reading the number back out of the file.

A refusal does not say which rule refused. pam_pwquality is in the same stack and refuses passwords for length, class and dictionary reasons. This test asserts the message - "already used" - so the assertion is tied to the history and not to whichever rule happened to object.

Getting the test client right took two attempts, and the failure looked like a policy refusal. Run as root, the passwd stack does not ask for the current password, so a change is TWO lines and not three; fed three, every change failed with "Sorry, passwords do not match", which reads exactly like a rule rejecting the password. And printf '%s' with no trailing newline leaves pamtester waiting on a line that never ends.

License

Commercial - IaC Bazaar EULA. (c) IaC Bazaar.