Hello,

I'm hoping someone can help me out here.

I have enabled Linux PAM (version 1.1.4) and cracklib (version 2.8.22) and most things are working fine. All password complexity specified via the PAM configuration file are being adhered to (upper/lower case, digits, etc) but the 'difok' is NOT being adhered to. No matter what I set this option to, pam_cracklib will let any password through (provided it meets the other complexity requirements I've specified).

Long story short I had to modify the Linux PAM cracklib to add some debug and quickly found out that pam_cracklib FAILS to be able to retrieve the OLD password. It thinks the string is NULL so naturally there is nothing to compare the new password to.

Yet when the user changes their own password, it IS CORRECTLY authenticating the current (what will become the OLD) password so pam_unix is correctly seeing the old password. By the time it gets down to the pam_cracklib line of the PAM configuration the password appears to have been wiped out somehow.

I'm pulling my hair out trying to figure out how/where/why this is happening.

Here are the relevant password lines in my PAM configuration file:

password requisite pam_cracklib.so debug reject_username\
minlen=6 ucredit=-1 lcredit=-1 difok=4 maxrepeat=2
password required pam_unix.so debug md5 shadow

BY THE WAY: this is all being done programatically through a front end application. This is NOT something which can be done interactively in this environment.

ALSO, in the PAM conversation function I print out the messages sent by the PAM library asking for information and it gets called 4 times but only once it asks for the OLD password. All other times it is asking for some variation of the new password.

The application is calling functions in the following sequence:

pam_start with pointer to the application PAM conversation function.

pam_authenticate - this DOES work correctly and validates the user password prior to allowing the change password to go forward.

pam_acct_mgmt

pam_chauthtok

I figured that either pam_chauthtok would either retrieve password from prior module or ask for it again via the PAM conversation function but neither one happens and when it gets to cracklib it sees the OLD password as NULL.

Does anyone have any ideas on this?

Thanks much
Allen

P.S. Hopefully I posted this in the correct place. Please let me know if I didn't.

Hello everyone,

I have solved this problem with a patch to Linux pam_cracklib.c. Just before 'pam_get_item' is called to retrieve the OLD password (PAM_OLDAUTHTOK) in function 'pam_sm_chauthtok' I inserted a call to 'pam_prompt' so that the conversation module on the application side is consulted again which sends the old password fresh back to Linux PAM.

This resolves the problem but I am really blown away by this because this should not have been necessary in my opinion. Is there something else I am missing or is this truly a bug in pam_cracklib which no one but me appears to have reported after all this time?

Any insight would be appreciated.

Thanks
Allen

I know, I'm quite late, but I have exactly the same problem just now on a old server and I'm heavily patching pam_cracklib.

Could you please post your solution? Just the line with pam_get_item, it should be enough.

I'm using debian wheezy.

It sound strange to me that nobody else had this problem.
I'm frustrated because I can't nothing about this, this is the first post I see!

Thanks