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:
^ ^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | | |
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: