October 05, 2005, 8:44 AM — While it's clearly possible to use the /etc/passwd and /etc/shadow files in Solaris and other Unix systems without making use of the password aging features, you could be taking advantage of these features to encourage your users to practice better security -- and, with the right password aging values, you can configure a good password-changing policy into your system files while limiting the risk that your users will be locked out of their accounts.
In this week's column, we look at the various fields in the shadow file that govern password aging and suggest settings that might give you the right balance between user convenience and good password security.
>b>The /etc/shadow File
To begin our review of how password aging works on a Solaris system, let's examine the format of the /etc/shadow file. Each colon-separated record looks like this:
johndoe:PaSsWoRdxye7d:13062:30:120:10:inactive:expire:
^ ^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | | |
username:password:lastchg:min:max:warn:inactive:expire:flag
The first field is clearly the username. The next is the password encryption. The third is the date when the password was last changed expressed as the number of days since January 1, 1970. The min field is the number of days that a password MUST be kept after it is changed; this is used to keep users from changing their passwords and then immediately changing them back to their previous values (thereby invalidating the intended security). The max field represents the maximum number of days that any password can be used before it is expired. If you want your users to strictly change their passwords every 30 days, for example, you could set both of these fields to 30. Generally, however, the max field is set to a considerably larger value than min. The warn field specifies the number of days prior to a password expiration that a user is warned on login that his/her password is about to expire. This should not be too short a period of time since many users don't log in every day and the display of this message in the login messages is easy to overlook.
The inactive field sets the number of days that an account is allowed to be inactive. This value can help prevent idle accounts from being broken into. The expire field represents the absolute day (expressed as the number of days since January 1, 1970) that the password will expire. You might use this field if you want all of your users' passwords to expire at the end of the fiscal year or at the end of the semester. The last field, flag, is unused until Solaris 10 at which point it records the number of
failed login attempts.
If the lines in your shadow file look like this:
sbob:dZlJpUNyyusab:12345::::::
The username and password are set and the date on which the password was last changed has been recorded, but no password aging is taking effect.
If it looks like this, the account is locked.
dumbo:*LK*:::::::
Various other combinations of the shadow file are possible, but the min, max and warn fields will only make sense if the lastchg field is set. For example:
jdoe:w0qjde84kr%p0:13062:60:::::
User must keep a password for 60 days once he changes it, but no password changes are required.
jdoe:w0qjde84kr%p0:13062::60::::
User must change his password every 60 days, but can change it at any time (including immediately changing it back to its previous value).
Choosing Min and Max Settings
If you want to turn on password aging, the combination of minimum (must keep) and maximum (invalid after) values enforces a practical password update scheme. Suggested settings depend in part on the security stance of your particular network. However, general consensus seems to be that passwords, once changed, should be kept for a month (min=30) and that passwords should be changed every three to six months (from max=90 to max=180).
Once a user has used a password for 30 days, he's probably not going to reset it back to its previous value. By then he should know it well enough to continue using it.
Changing a password more often than every month or so would probably make it hard for users to remember their passwords without writing them down.
The down side of min values is that this setting doesn't allow someone to change his password if he believes it has been compromised when the compromise happens within the "min" period. Whatever system you adopt should, therefore, make it painless for a user to request that his password be reset whenever he believes it may no longer be secure.
Wrap Up
