From sacadmin Fri Dec 13 13:33:23 2002 Date: Fri, 13 Dec 2002 13:32:53 -0800 (PST) From: Gary Winiger To: psarc@sac.eng.sun.com Subject: PSARC/2002/680 Password History Checking Cc: darren.moffat@sun.com, joep.vesseur@sun.com, claudette.cresswell@sun.com, glenn.brunette@sun.com, george.fytikas@sun.com Content-Length: 7976 I'm self-sponsoring this fast-track. It requests a patch release binding (and was my skunk works project while on sabbatical ;-) The interface taxonomy for passwd(1), pam_authtok_check(5), and /etc/default/passwd remain Evolving. The taxonomy of the database is described in the Details section below. The timer is set for 20 Dec. 2002. Gary.. ================================================================== Background: Many field requests have been received to support prior password history checking when passwords are changed (see RFE 4473400). Other vendors such as HP, IBM, Linux offer it and Solaris is being viewed as behind the security curve for not offering password history checking. SunPS is providing specials for customers who are being told they must have this feature or not purchase from Sun. A common argument against this "feature" is that it is not implementable across the various naming services. The field and SunPS input is that local file accounts (passwd(4)/shadow(4)) will satisfy the customers and allow Sun to make sales. It would be possible to add this feature to writable name services but Solaris doesn't presently support general updates through NSS. (PSARC/2002/270 - pam_ldap account control - provides optional support for password history when using iDS 5.x as the account authority, not as the name service repository.) During the design review, a reviewer expressed concern that too many things were being integrated into the pam_authtok_check(5) service module and that it this project should not be added there. The project team feels strongly that pam_authtok_check(5) is the appropriate place to add the password history feature. All other password strength features have been added there (see PSARC/2002/383 Parameterized Password Strength Checking). Moving this feature to a separate PAM service module would require additions to both pam.conf(4) and /etc/default/passwd and be more complex for the customer. The password history feature proposed here, just as all the other /etc/default/passwd features proposed in PSARC/2002/383 may be disabled. The only pam_authtok_check(5) feature that is not (yet) configurable is the login name check. To allow the customer to access whatever combination of password strength features are available with pam_authtok_check(5), so that its removal is not necessary for customers wanting to do custom password strength checking, this project proposes to complete the missing parameterization. It will be important to set customer expectations correctly. Please help review the details to ensure that the proposed information will do so. Solution: For accounts defined in local files only, a password history will be maintained of up to 26 priorly changed passwords. Add a new keyword, "HISTORY", to /etc/default/passwd to define the number desired. The maximum of 26 comes from a common practice of requiring password changes every month. This will allow for two years password history or one years of every two week changes. (The Windows/XP limit is 24.) An arbitrary number could be allowed, but this seemed excessive. 26 prior passwords will be kept so that an administrator may increase the number at any time up to 26 and have the new policy immediately enforced. The default is zero (0). The current Solaris behavior is preserved. Setting the HISTORY value to zero will cause all users' password history to be discarded at the next password change by any user. To complete the parameterization of password strength checking, add a new keyword, "NAMECHECK", to /etc/default/passwd to enable/disable login name checking. If unspecified, login name checking is done. Details: A Project Private password history file (/etc/security/passhistory) is automatically created and removed at the time any local user changes a password. It is created, if needed, if /etc/default/passwd:HISTORY has a non-zero value. It is removed, if it exists, if the HISTORY value is zero (the default for a missing HISTORY keyword). The contents of passhistory is Internal. It consists of colon separated lines of the form "user:cryptedpw1:cryptedpw2: ..." The prior passwords retained are the crypt(3C) form as they would be in shadow(4). pam_authtok_check(5) is modified to check the user's password history, up to HISTORY for a reuse of a prior password. Root is still exempt from password quality checks. During update of passhistory Project Private files /etc/security/pwhistemp and /etc/security/opwhistory are used. The update is synchronized by the existing global locking done during every local account password update. /etc/default/passwd class action is preserve, this project does not propose a change. The following man page changes are made. Full diff marked man pages are in the case directory. A proposed /etc/default/passwd is also in the case directory. passwd(1): Passwords must be constructed to meet the following require- ments: o Each password must differ from the user's login name and any reverse or circular shift of that login name. For comparison purposes, an upper case letter and its corresponding lower case letter are equivalent. + This check may be disabled in /etc/default/passwd. + o For local accounts, if prior password history is defined, + new passwords must not be contained in the prior password + history. FILES /etc/default/passwd Default values can be set for the following flags in /etc/default/passwd. For example: MAXWEEKS=26 + NAMECHECK + Enable/disable login name checking. + The default is to do login name checking. + A case insensitive value of "no" disables this + feature. + HISTORY + Maximum number of prior password history to keep for + a user. Setting the HISTORY value to zero (0), + or removing the flag will cause all users' prior + password history to be discarded at the next + password change by any user. The default is + not to define the HISTORY flag. The maximum value + is 26. + Note: This feature is only enforced for user + accounts defined in the local passwd(4)/shadow(4) + files. pam_authtok_check(5): The checks performed by this module are: circular shift The password should not be a circular shift of the ! login name. This check may be disabled in ! /etc/default/passwd. variation The old and new passwords must differ by at least ! three positions. For local accounts, if prior history + is defined, the new password must not match the prior + passwords. FILES /etc/default/passwd Contains the value for PASSLENGTH, the default minimal password length. + Contains the value for NAMECHECK used to determine if + login name checking is enforced. + Contains the value for HISTORY, the number of prior password + history elements to compare with the current password. + Note: This feature is only enforced for user accounts + defined in the local passwd(4)/shadow(4) files. passwd.dfl: # NAMECHECK enables/disables login name checking. # The default is to do login name checking. # Specifying a value of "NO" will disable login name checking. # #NAMECHECK=NO # HISTORY sets the number of prior password changes to keep and # check for a user when changing passwords. Setting the HISTORY # value to zero (0), or removing/commenting out the flag will # cause all users' prior password history to be discarded at the # next password change by any user. No password history will # be checked if the flag is not present or has zero value. # The maximum value of HISTORY is 26. # # This flag is only enforced for user accounts defined in the # local passwd(4)/shadow(4) files. # #HISTORY=0 From sacadmin Mon Dec 16 13:51:34 2002 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 16 Dec 2002 16:50:49 -0500 From: James Carlson To: Gary Winiger Cc: psarc@sac.eng.sun.com, darren.moffat@sun.com, joep.vesseur@sun.com, claudette.cresswell@sun.com, glenn.brunette@sun.com, george.fytikas@sun.com Subject: Re: PSARC/2002/680 Password History Checking Content-Length: 1722 Gary Winiger writes: > A Project Private password history file (/etc/security/passhistory) > is automatically created and removed at the time any local user changes a > password. It is created, if needed, if /etc/default/passwd:HISTORY has a > non-zero value. It is removed, if it exists, if the HISTORY value is zero > (the default for a missing HISTORY keyword). The contents of passhistory is > Internal. Just a really tiny nit: the contents look Project Private to me. > + HISTORY > + Maximum number of prior password history to keep for > + a user. Setting the HISTORY value to zero (0), > + or removing the flag will cause all users' prior > + password history to be discarded at the next > + password change by any user. The default is > + not to define the HISTORY flag. The maximum value > + is 26. Random question: if I wanted to clear all of the history immediately for all of the users or for a specific user, how would I do that? (This history would make a handy input for Crack5 if I were redeploying a machine.) > + Note: This feature is only enforced for user > + accounts defined in the local passwd(4)/shadow(4) > + files. It would sort of be nice to define this feature such that it works for any backend that has the capability of checking password history, rather than tying it specifically to passwd/shadow. -- James Carlson, Solaris Networking SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Tue Dec 17 09:36:18 2002 Date: Tue, 17 Dec 2002 09:35:44 -0800 (PST) From: Gary Winiger To: gww@marduk.eng.sun.com, james.d.carlson@east.sun.com Subject: Re: PSARC/2002/680 Password History Checking Cc: psarc@sac.eng.sun.com, darren.moffat@sun.com, joep.vesseur@sun.com, claudette.cresswell@sun.com, glenn.brunette@sun.com, george.fytikas@sun.com Content-Length: 2558 > > (the default for a missing HISTORY keyword). The contents of passhistory is > > Internal. > > Just a really tiny nit: the contents look Project Private to me. Correct. The contents do go across an interface that is not internal to a single executable. I was too cautious. The spec will be updated to Project Private. > > + HISTORY > > + Maximum number of prior password history to keep for > > + a user. Setting the HISTORY value to zero (0), > > + or removing the flag will cause all users' prior > > + password history to be discarded at the next > > + password change by any user. The default is > > + not to define the HISTORY flag. The maximum value > > + is 26. > > Random question: if I wanted to clear all of the history immediately > for all of the users or for a specific user, how would I do that? > (This history would make a handy input for Crack5 if I were > redeploying a machine.) To do so for all users, as an administrator with write access to /etc/default/passwd, remove (comment out, or set the value to 0) the HISTORY line. Then change any password to its existing value. (In practical terms, this really means running as root, because there are no administrative interfaces for /etc/default/* beyond your favorite editor. Then change the root password to itself.) For individual users there is no interface. The customer requirements that generated this RFE seem to be met by the proposed case. The project team believes the project is complete. If needed, a follow on project could change the passwd command to allow clearing history on a per user basis. > > + Note: This feature is only enforced for user > > + accounts defined in the local passwd(4)/shadow(4) > > + files. > > It would sort of be nice to define this feature such that it works for > any backend that has the capability of checking password history, > rather than tying it specifically to passwd/shadow. Yup. The project team should have made the wording general, just like the account locking (PSARC/2002/518) ;-). The project team will update the spec with words like: "For accounts in name services which support password history checking, if priory password history is defined, new passwords must not be contained in the prior password history." and "Currently only the "files" name service (passwd(4)/shadow(4)) support password history checking." Gary.. From sacadmin Tue Dec 17 14:12:41 2002 Date: Tue, 17 Dec 2002 14:12:05 -0800 (PST) From: Gary Winiger To: gww@marduk.eng.sun.com, james.d.carlson@east.sun.com Subject: Re: PSARC/2002/680 Password History Checking Cc: psarc@sac.eng.sun.com, darren.moffat@sun.com, joep.vesseur@sun.com, claudette.cresswell@sun.com, glenn.brunette@sun.com, george.fytikas@sun.com Content-Length: 1639 I've updated the spec and man pages in the case directory. To summarize: 1) The contents of /etc/security/passhistory as well as the name is Project Private. 2) The description of support for password history in passwd(1) now reads: Passwords must be constructed to meet the following requirements: + o For accounts in name services which support password history + checking, if prior password history is defined, new passwords + must not be contained in the prior password history. FILES /etc/default/passwd + HISTORY ..... + Note: currently this functionality is enforced only + for user accounts defined the "files" name service + (local passwd(4)/shadow(4)). 3) The description of support for password history in pam_authtok_check(5) now reads: variation The old and new passwords must differ by at least ! three positions. For accounts in name services which + support password history checking, if prior history + is defined, the new password must not match the prior + passwords. FILES /etc/default/passwd + Contains the value for HISTORY, the number of prior password + history elements to compare with the current password. + Note: Currently this feature is only enforced for user accounts + defined in the "files" name service (local passwd(4)/shadow(4)). Gary.. From sacadmin Wed Dec 18 10:02:22 2002 Date: Wed, 18 Dec 2002 10:02:03 -0800 (PST) From: Darren J Moffat To: Gary Winiger cc: psarc@sac.eng.sun.com, , , , Subject: Re: PSARC/2002/680 Password History Checking MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 376 On Fri, 13 Dec 2002, Gary Winiger wrote: > A Project Private password history file (/etc/security/passhistory) > is automatically created and removed at the time any local user changes a > password. Why is this growing file in /etc/security rather than in the already existing /var/adm/passwd directory (I have no idea what that dir is actually for). -- Darren J Moffat From sacadmin Wed Dec 18 12:34:09 2002 Date: Wed, 18 Dec 2002 12:33:31 -0800 (PST) From: Gary Winiger To: gww@marduk.eng.sun.com, Darren.Moffat@Sun.COM Subject: Re: PSARC/2002/680 Password History Checking Cc: psarc@sac.eng.sun.com Content-Length: 521 > Why is this growing file in /etc/security rather than in the already > existing /var/adm/passwd directory (I have no idea what that dir is > actually for). The /etc/security/passhistory file is bounded in size the same as the /etc/password file. The project team believe that it is appropriate to have the password history file on the same file system as the password and shadow files. The project team is unaware of use of the /var/adm/passwd directory, and notes that it is owned by adm with group adm. Gary.. From sacadmin Wed Dec 18 12:35:10 2002 Date: Wed, 18 Dec 2002 12:34:32 -0800 (PST) From: Gary Winiger To: psarc@sac.eng.sun.com, gww@marduk.eng.sun.com Subject: Re: PSARC/2002/680 Password History Checking Cc: darren.moffat@sun.com, joep.vesseur@sun.com, claudette.cresswell@sun.com, glenn.brunette@sun.com, george.fytikas@sun.com Content-Length: 57 This case was approved at today's PSARC meeting. Gary..