Description of problem: pam_pwquality documentation defines "difok=" as an option. It cannot be set in the /etc/pam.d/* files. A reading of the course for that module shows it doesn't even check for that option. (It does check for, and ignore, "difignore=".) While it can be set in the /etc/security/pwquality.conf file, the source code reveals it cannot be set to zero any longer. (Due to an old check that the distance must also be greater than the default, which is currently "1".) (I cannot be certain that is the cause; maybe there is another check that prevents reusing the current password, that is undocumented. My memory is that pam_cracklib did allow you to reuse your current password when difok was set to zero.) Version-Release number of selected component (if applicable): 1. pam-1.2.1-2.fc23.x86_64 How reproducible: always Steps to Reproduce: 1. Edit /etc/pam.d/system-auth and add "difok=0" to the pwquality module's arguments. 2. Edit /etc/security/pwquality.conf and add "difok=0". 3. Login as a regular user, and try to change the password to the same one. Actual results: BAD PASSWORD: The password is the same as the old one Expected results: passwd: all authentication tokens updated successfully. Additional info: Source code checked from <https://fedorahosted.org/libpwquality/browser/src/check.c?rev=a4696cd7cd246f6c34a2d2f1d54d569c5e7ecd84>
I think I found part of the problem. These lines in the check.c: 663 if (oldpassword && strcmp(oldpassword, password) == 0) { 664 return PWQ_ERROR_SAME_PASSWORD; 665 } 666 also need to check that difok wasn't zero. Note the other part of this bug: that pam_pwquality.c <https://fedorahosted.org/libpwquality/browser/src/pam_pwquality.c> doesn't seem to check for difok= as an argument.
No, pam_pwquality checks for difok= by means of pwquality_set_option(pwq, *argv). So it definitely is not ignored if set on the module command line. However as you correctly found it is not possible to allow for having the new password same as the old one if difok is set to 0. It is not true though that this is any different from pam_cracklib. The check from comment 1 is present in pam_cracklib too and will make it to error out in a similar way.
There is no point in enabling such functionality. Also a future libpwquality release will enable difok=0 to mean switch off all the old password similarity checks except for the password being exactly the same which I think is much more useful.