openwall / passwdqc

Password/passphrase strength checking and policy enforcement
https://www.openwall.com/passwdqc/
Other
40 stars 17 forks source link

pam_passwdqc auto-generated policy description is misformatted since 1.4.0 #3

Closed solardiz closed 3 years ago

solardiz commented 3 years ago

With introduction of i18n support in 1.4.0, the auto-generated English description of the password policy changed. For the defaults, we previously had:

A valid password should be a mix of upper and lower case letters,
digits, and other characters.  You can use an 8 character long
password with characters from at least 3 of these 4 classes, or
a 7 character long password containing characters from all the
classes.  An upper case letter that begins the password and a
digit that ends it do not count towards the number of character
classes used.

Now we have:

A valid password should be a mix of upper and lower case letters,
digits, and other characters.  You can use a password
that consists of 8 characters from at least 3 of these 4 classes, or

a password containing 7 characters from all the classes.
An upper case letter that begins the password and a
digit that ends it do not count towards the number of character
classes used.

(The description regarding passphrases remained the same, so I don't include it above.)

I think it's wrong that we have an empty line after , or - in fact, I don't immediately see where that extra linefeed comes from, maybe it's somehow system-specific? The above is seen on Owl-current and on CentOS 7. I didn't test elsewhere.

Also, I think it's bad that the lines are now wrapped at inconsistent lengths. We should correct this if we can.

OTOH, the changes in the wording are maybe to the better - the previous wording might have encouraged use of passwords of exactly those minimum lengths. Now we use wording "that consists of" and "containing", which implies it's at least OK for the password not to be limited to that. As a further improvement, I think we should change "that consists of" to "containing", too. So if we can, I'd like to see:

A valid password should be a mix of upper and lower case letters,
digits, and other characters.  You can use a password containing
8 characters from at least 3 of these 4 classes, or a password
containing 7 characters from all the classes.

An upper case letter that begins the password and a digit that ends
it do not count towards the number of character classes used.

BTW, someone had opened a related Debian "bug" - not about the misformatting we got in 1.4.0+, but about improving those messages in general:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835067 libpam-passwdqc: improvements(?) to password prompting

This includes a patch against 1.3.0 that changes the wordings in some ways. I didn't review it, but I think it's worth taking another look at when revising the wording further.

I am assigning this to @ldv-alt, but really I think any capable maintainer from ALT Linux should contribute on this issue. We got the i18n support from ALT Linux (thanks!) and I'd like it to be maintained by ALT Linux folks. Otherwise I'd end up regretting having encouraged its merge from ALT Linux, which I did thinking it'd simplify merges of my other changes to passwdqc into ALT's package.

I don't have time to fight i18n support peculiarities, and if I have to work on this issue alone I'd start by dropping i18n support at least for the auto-generated messages.

In fact, it's also been requested (a few times over many years) that pam_passwdqc should allow the sysadmin to specify a fully custom new password prompt, perhaps with a manually pre-specified policy description in there. This would also allow for those messages to be in any language. It would then be the sysadmin's responsibility to keep this description consistent with actually enforced policy. Unfortunately, I expect these will often end up inconsistent on specific systems, but perhaps we should add this feature anyway (would be a separate GitHub issue/PR from this one, but I mention it here since it's related to possible direction we might take here if dropping i18n support for these messages is within consideration).