password aging and that screwy base 64 date

[Russ Jones_1]

We're going to turn on password aging for some 10000+ users, and since we don't want all 10000 of them having to change their password on the same day, we're going to run a script that creates that ,xxxx extension to the password hash in the /etc/passwd file (okay, it's really in the NIS passwd map, but that's close enough for this question) to spread out the expirations over a number of weeks or months.

The book "HP-UX 11i Security" by Chris Wong (published by HP Professional Books, so you'd think it knew what it was talking about) says that the last two bytes of the extension is "weeks (in base 64) since 1970 when password was last changed..." (page 46). This makes sense, since 1970 is a really familiar date to all us Unix weenies.

But in practice, when we have aging turned on and we change a password, it looks like the system is setting that field to weeks since 1988 or there abouts. Am I just nuts or is there something I've overlooked, or is the book wrong or what?

Any hints will be greatly appreciated.

[A. Clay Stephenson]

No, the aging counts off the number of weeks since Jan 1, 1970 00:00:00 UTC. That fell on a Thursday, so all weeks start on a Thurdays for our purposes. You are being confused because the most significant portion of the two-digit base-64 values is the last character. Multiply the last character's value by 64 and add it to the next-to-last base-64 characters values and then the week numbers begin to make sense.

[Massimo Bianchi]

Hi,
quoting from the "man 4 passwd"

UNIX keeps internal time stamps in a format with a base date of
Thursday January 1, 1970. Because of this, passwd considers the
beginning of a week to be 00:00 GMT Thursday.

The first character of the age, M, denotes the maximum number of weeks
for which a password is valid. A user who attempts to login after his
password has expired is forced to supply a new one. The next
character, m, denotes the minimum period in weeks that must expire
before the password can be changed. The remaining two characters
define the week when the password was last changed (a null string is
equivalent to zero). M and m have numerical values in the range 0
through 63 that correspond to the 64-character set of "digits" shown
above.

If m = M = 0 (derived from the string . or ..), the user is forced to
change his password next time he logs in (and the "age" disappears
from his entry in the password file). If m > M (signified, for
example, by the string ./), then only a superuser (not the user) can
change the password. Not allowing the user to ever change the
password is discouraged.



Looks like that's true.

HTH,
Massimo

[Victor Fridyev]

Hi,

If you do
man 4 passwd
you find some explanation of password aging for HPUX. The coding of aging is very smart, they use reverse order, i.e. if you want to calculate the aging for ABCD, you have to do: D*64+C.
You can simplify the process:
Write a script, which will write
,B/..
at the end of the password field. This defines 90 days password life and requires to change the existing password with the first login attempt.
You can use the script from crontab for a group of users, let's say 100-200 users per day and by such a way you complete the mission in a couple of months. Please take into account that such an aging doesn't work for LINUX and Solaris, only for HPUX
HTH

[Russ Jones_1]

When we reset a password on our test system, we came up with this in /etc/passwd:

jeff:Jg4uAVz/ogxIg,3/DQ:9899:286:JeffTest:/tmp:/bin/ksh

You can see that the "weeks since password was last set" part is DQ which decodes to (15 * 64) + 28, which is 988. 988 / 52 weeks is 19 years, 19 years plus 1970 is 1989. That's what I don't get. We did this a couple of weeks ago, not in 1989.

[john kingsley]

No, it is since 1970.
For example try the following:
user1:--hash---,41/.:uid:gid:....etc
"/." represents that data PW was last changed.

Then run:
passwd -s -a
user1 PS 01/08/70 0 42

Don't forget, "."=0, "/"=1, 0-9=2-11, A-Z=12-37, a-z=38-63

[A. Clay Stephenson · Accepted solution]

Your numbers make perfect sense:

Q = 28
D = 15

(28 * 64) + 15 = 1807

Now let's use caljd.sh to see if this makes sense (search the Forums for this script - Version 2.23 is the latest)

Today's Julian Day:
caljd.sh
2453245
1-Jan-1970 CE's Julian Day = 1808

It looks like your most recent passwd change was done last week (or at least before Thurday).

caljd.sh 1 1 1970
2440588

Difference in days
2453245 - 2440588 = 12657
Diffence in weeks (integer math)
12657 / 7 = 1808

[Russ Jones_1]

NOW it makes sense. The example in the book shows a last change number of HN, then they say it's (19 * 64) + 25, which it would be if the high order digit was the H. But if the second character is the high order digit, (small-endian, right?) it makes so much more sense. We just changed that password again, and got EQ, which is this week, not last week.

Thanks!

[A. Clay Stephenson]

Actually Russ, I told you that in my first response.