Fedora Account System
Red Hat Associate
Red Hat Customer
Currently libpwquality.conf file specifies over 10 different options. Configuring it in a way that meets NIST SP 800-63-1 requirements is hard or at least non trivial. It should be possible to set a single variable, specifying the required security level that would guarantee safe operation, in a manner similar to FIPS mode. (this will probably require ability to measure password guessing entropy and support from different pam_modules to enforce rate limiting)
I would not mix configuration of multiple PAM modules into one file. Other than that it makes sense though.
I agree, what I had in mind is that to achieve full NIST SP 800-63-1 conformance will need help from other modules in authentication stack, as neither libpasswdqc nor cracklib is the right place for rate limiting.
(In reply to Hubert Kario from comment #0) ... > It should be possible to set a single variable, specifying the required > security level that would guarantee safe operation, in a manner similar to > FIPS mode. ... Excellent suggestion. The required security level should also be configurable on the pwscore command-line, so that users can specify the required strength depending on the intended application. Currently, pwscore has no command-line options whatsoever corresponding to the options in libpwquality.conf. libpwquality-1.2.2-1.fc19.x86_64
BTW, there is a FutureFeature keyword that is intended for RFEs: FutureFeature Add this keyword if this issue refers to a feature you would like to see in a future release of a Red Hat product. https://bugzilla.redhat.com/describekeywords.cgi
(In reply to Steve Tyler from comment #3) > The required security level should also be > configurable on the pwscore command-line +1 (In reply to Steve Tyler from comment #4) > BTW, there is a FutureFeature keyword that is intended for RFEs: > > FutureFeature Add this keyword if this issue refers to a feature you would > like to see in a future release of a Red Hat product. > https://bugzilla.redhat.com/describekeywords.cgi True. Forgot about it. Thanks!
(In reply to Steve Tyler from comment #3) ... > Excellent suggestion. The required security level should also be > configurable on the pwscore command-line, so that users can specify the > required strength depending on the intended application. > > Currently, pwscore has no command-line options whatsoever corresponding to > the options in libpwquality.conf. ... Bug 1003941 - [RFE][usability] pwscore command-line options to override options in libpwquality.conf
For reference, here are the NIST documents: SP 800-63-2 (Draft) Feb. 1, 2013 DRAFT Electronic Authentication Guideline Announcement and Draft Publication http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-63--2 http://csrc.nist.gov/publications/drafts/800-63-2/sp800_63_2_draft.pdf NB: The public comment period for SP 800-63-2 (Draft) closed on March 4, 2013. SP 800-63-1 Dec 2011 Electronic Authentication Guideline http://csrc.nist.gov/publications/nistpubs/800-63-1/SP-800-63-1.pdf Appendix A: Estimating Entropy and Strength Password Entropy A.1 Randomly Selected Passwords A.2 User Selected Passwords A.3 Other Types of Passwords
The current revision of the standard does not have any particular requirements on memorized passwords but instead focuses on multi-factor authentication. I am closing this RFE for now.
SP 800-63-3B still requires rate limiting: Verifiers SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account as described in Section 5.2.2. and still recommends that the password black list should include Context-specific words, such as the name of the service, the username, and *derivatives* thereof.
The first requirement is not related to libpwquality and the second one is already implemented (although it might be debatable whether the implementation is sufficient or not).