Password Quality Scored At The Boundary

password-quality

A password policy proven with passwords. pam_pwquality is already in EL's authentication stack, so the role owns the policy file and nothing else. The live test scores four passwords against the live policy and checks the REASON for each refusal: a password built on a dictionary word, a strong password one character under the minimum, the same password at the minimum, and a passphrase the policy must not refuse.

No download, and no version to pin. libpwquality is part of EL 10 and its PAM module is already in the stack. What the role owns is the policy: how long, how varied, and what a password may not contain.

enforce_for_root is in the shipped policy on purpose. Without it, root setting a password for another account bypasses every rule in the file, which is how most of these policies come to be decorative.

chpasswd run as root bypasses pwquality entirely. Measured: with this policy in force, echo user:password | chpasswd succeeded. A test that set a password as root and called that a pass would prove nothing at all, so the live test uses pwscore, which scores against the live policy and exits non-zero when the policy refuses.

Nothing validates the policy file. An unknown key is ignored, so a typo leaves a policy that reads strict and is not. That is why the test asserts the length rule at its BOUNDARY - one character under the minimum must fail and the minimum must pass - rather than reading the number back out of the file it just wrote.

maxclassrepeat shadows every other rule, so this policy disables it. The setting refuses a password with more than N consecutive characters of one class. At 4, the value hardening notes usually give, it decides almost every case before any other rule is consulted. Measured in this role's lane with pwscore, one password per row and only maxclassrepeat changed between columns:

password	= 0 (shipped)	= 4	= 8
Correct-Horse-9x-Battery	accepted, 100	refused, class run	accepted, 100
Inte1rnat2iona3lism4!	accepted, 90	accepted, 90	accepted, 90
Str4wberry!Fields	accepted, 62	refused, class run	accepted, 62
Internationalism1!	refused, dictionary	refused, class run	refused, class run
Zx9#Qw7!Lm2$Kp	accepted, 40	accepted, 40	accepted, 40

At 4 the rule refuses the strongest password in the set and accepts an interleaved dictionary word, and it silences the dictionary check completely: with the rule at 4, not one verdict in a nine-password probe changed between dictcheck = 1 and dictcheck = 0. With the rule disabled, exactly one of those nine separates them, and that is the password the live test now scores. Set password_quality_maxclassrepeat if a baseline demands the literal setting, and know what it costs.

A refusal does not say which rule refused. This test previously scored password and read its refusal as proof of the dictionary check; pwquality was refusing it for consecutive lowercase letters, and would have gone on refusing it with dictcheck = 0. Every refusal the live test asserts now carries the reason pwquality gave for it.

License

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