pam_passwdqc vs pam_cracklib

Steve Grubb sgrubb at redhat.com
Fri Sep 28 15:44:02 UTC 2012


On Friday, September 28, 2012 02:53:22 PM Spencer R. Shimko wrote:
> On Sep 28, 2012, at 9:50 AM, Steve Grubb <sgrubb at redhat.com> wrote:
> > On Friday, September 28, 2012 01:27:25 PM Spencer R. Shimko wrote:
> >> Is anyone strongly bound to pam_cracklib?  The reason I ask is that the
> >> prose and OVAL checks are currently written for pam_cracklib. 
> >> pam_cracklib
> >> doesn't enforce complexity requirements on UID 0.  pam_passwdqc can
> >> enforce
> >> password complexity requirements on root with the "enforce=everyone"
> >> option.  Many requirement sets do not differentiate between privilege
> >> users
> >> and unprivileged users in the I&A sections.  As a result I'd like to
> >> switch
> >> to passwdqc.  Unless there is opposition we'll put together a patch to
> >> make
> >> the switch.
> > 
> > Yes, I would prefer to stay with pam_cracklib for a number of reasons. If
> > there were a deficiency in it, I'd rather open a bug report and fix it.
> 
> We did open a bug - way back in 2010 :P
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=588893
> 
> I had hoped the feature would have been integrated into a release by this
> point but at least it is being considered for RHEL 6.4.  

It will be in the 6.4 release. the bug was filed against RHEL5 and that's why 
it languished. Its on its way now.


> Until the feature is released I'm going to have to stick with passwdqc and
> will use SecState's mitigation feature to explain why we fail that check and
> why it is a false negative.
> 
> Can you share those reasons you prefer cracklib?  

Because of 2 reasons. 1) when password requirements come in, we have 2 
packages to update. The pam package always has priority and gets updated more 
often than pam_passwdqc.  2) Because of this, it also has capabilities that 
pam_passwdqc does not have like the maxclassrepeat and reject_username  
directives that were also govt requirements. See bz 673398.


> I'm perfectly fine sticking with cracklib if this feature is added.  I do
> like passwdqc's simplicity though.

I'd suggest enforcing this on 6.4 and higher. Its unfortunate the bug didn't 
get reclassified to rhel6 faster. But its the best path forward for everyone's 
requirements.

-Steve


More information about the scap-security-guide mailing list