Friday, October 07, 2005

Password Aging

Password Aging, Part 1, Unix in the Enterprise 10/4/05

Sandra Henry-Stocker,

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

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:


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

If it looks like this, the account is locked.


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:


User must keep a password for 60 days once he changes it, but no
password changes are required.


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

We hear a lot about the tradeoff between security and convenience as
it permeates so many of our decisions about how we manage our networks
but, when it comes to passwords, we must be careful not to cross the
line between securing logins and preventing them altogether. Locking
our users too easily out of their accounts can reduce security as
easily as enhance it. Using password aging with the proper settings
can limit the risk that security constraints turn into unintended
denials of service.

Next week, we'll look at how to introduce password aging on a system
where users have never had their passwords expire.


Post a Comment

<< Home