Friday, October 14, 2005

Password Aging, Part 2

Password Aging, Part 2

If you're starting with a group of users who have been active for a
long time and not had their passwords aged, how should you go about
introducing password aging?

To start, you might first take a look at the dates on which your
users' passwords were last changed. To view the dates by themselves,
you might use a command such as this (run as root):

# cat /etc/shadow | awk -F: '{print $3}' | sort -n | uniq -c

This command sorts the lastchg (last time the password was changed)
field numerically and prints out the number of records with each
particular date value.

Of course, the dates in this command's output are going to be
presented to you as a list of numbers (rather than recognizable
dates). You will see something that looks more or less like this:

7 6445
1 11289
2 11632
53 11676
5 11677
2 11683
1 11849
2 12038
23 12345
1 12881
1 13062

These numbers are a little hard to interpret, but the range of values
and the "popular" values suggest that most users on this system have
not changed their passwords in a very long time and that many of them
might have last changed their passwords in response to a request to do
so (since two groups of people changed their passwords on the same two

But let's try to pin these numbers down and get an idea what dates we
are really looking at. How do you do this? Well, if you have the GNU
date command installed on your system, you can view today's date with
a command such as this:

% expr `date +%s` / 86400

Alternately, you can package this date conversion command in in a
script such as that shown below, call it "today" and run it whenever
you want to know what the current date looks like in the
days-since-the-epoch format. If you're reading this column on the day
that it was first published, that value would be 13062.

#!/usr/bin/perl -w
# today: a script to print date in days-since-epoch format

$now=`/usr/local/bin/date +%s`;
$_=$now / 86400;
($today)=/(\d+)./; # number of days since 01/01/1970

print "$today\n";

In both the command and the "today" script, we use the "date +%s"
command to produce the current date/time as the number of seconds
since midnight on January 1, 1970. We then divide this value by the
number of seconds in a day (86,400) to convert this value to the
number of days since January 1, 1970. The commented line lops off the
digits on the right side of the decimal point (along with the decimal
point itself). This gives us a value for today.

To determine how long ago one of the other dates in the lastchg list
above happened to be, we can use an expr to calculate the number of
days between today and the date the password was last changed. Let's
choose the most popular value (line 4) for this:

# expr 13062 - 11676

That's 1,386 days ago -- nearly four years! NOTE: The shadow records
with 6445 in the lastchg field are disabled accounts and, thus, don't
factor into our password aging concerns.

If the bulk of your users have the same last-set date, they have
probably never changed their passwords -- or never changed them since
they were last required to do so. Whenever you change a user's
password or one of your users changes his own password, that field in
the /etc/shadow file will be updated.

So, how do you introduce password aging in a situation such as this?
If you add a max value when a user's password hasn't been reset for
nearly four years, chances are that his password will already be
expired and he will not be able to log in.

A better approach would be to initiate password aging by modifying the
lastchg date in your shadow records and then selecting a max value
that will give your users time to change their passwords before they
run out of time. You should also publish notices explaining the change
and focusing your users attention on the need to change their
passwords from time to time.

For example, if you make the lastchg date of a record five months in
the past and then require that the user change his password every six
months, this would give him a month to change his password before he
is locked out. And, from that point forward, he would need to change
his password every six months.

Five months in the past would roughly put the (fictitious) lastchg
date at 12912 (13062 - (5 * 30)). A shadow entry such as that shown
below would, therefore, force sbob to change his password within the
month and would give him a month's worth of warnings before he's
locked out of his account:


On login, sbob would see something like this:

Your password will expire in 30 days.
Last login: Wed Oct 6 16:28:34 2005 from
Sun Microsystems Inc. SunOS 5.8 Generic February 2005

If you've never used password aging before, it's probably a good idea
to get your users' attention to the fact that passwords are going to
expire. The one-line warning above may not be enough to get your
users' attention. Perhaps a notice like this in your /etc/motd file
would be more effective:

>>> Passwords must be changed every 6 months <<<
>>> Look for password expiration information <<<
>>> in the system output above <<<

When a message like this is displayed on login for a month, your users
are likely to notice and take action before their passwords expire.

You can also change the default settings for password aging in the
/etc/default/passwd file. For example, if you want users to be
required to keep a password for a month and change it every 6 months,
your values might look like this:


Next week, we will look at a script that analyzes the aging parameters
in the /etc/shadow file and warns you about users who are getting
close to their password expiration dates.


Post a Comment

<< Home