Why does HPUX11 age passwords on a friday?

[SAKERA PATEL]

HPUX B.11.00

Why does HPUX login age passwords on a friday instead of a thursday
when using the unix password database password ageing (pw_age)?

The first day of the week is Thursday for password ageing based on week
no since 1-Jan-1970 so why does the HPUX login not prompt for password
change until 00:00 on Friday?

Example:

I change my password on Thursday Nov 3rd at 12 midday.

Time Now..: 1131019205 Thu Nov 3 12:00:05 2005
Today.....: 13090
Week No...: 1870
Week Start: 13090
Week Start: 1130976000 Thu Nov 3 00:00:00 2005
Next Week : 1131580800 Thu Nov 10 00:00:00 2005

My password age is set to 1 week, when should I expect to have to
change my password again? Thursday Nov 10th at midnight surely
(Beginning of Week No 1871):

Time Now..: 1131624003 Thu Nov 10 12:00:03 2005
Today.....: 13097
Week No...: 1871
Week Start: 13097
Week Start: 1131580800 Thu Nov 10 00:00:00 2005
Next Week : 1132185600 Thu Nov 17 00:00:00 2005

But HPUX11 does not prompt me for a new password until 00:00 on Friday
Nov 11th.

Another example:
Password changed Nov 7, again set to age 1 week, HPUX11 lets me in on
Nov 10th (thursday, start of next week) and prompts to change password
on Friday 11th.

Is this a bug in HPUX?
or perhaps my mis-interpretation of the password aging algorithm (in
which case, in what way? what is the correct algorithm)
or is my math just screwed?

Thanks

[A. Clay Stephenson]

More data is required. First of all, the epoch seconds are based on UTC so if you are in another TZ then your numbers can be skewed. Secondly, the weeks since 1-Jan-1970 00:00:00 UTC only apply if you are an untrusted system. Password aging under trusted systems can do more precise math that untrusted because now the resolution is seconds rather than weeks.

[A. Clay Stephenson]

More data are required. First of all, the epoch seconds are based on UTC so if you are in another TZ then your numbers can be skewed. Secondly, the weeks since 1-Jan-1970 00:00:00 UTC only apply if you are an untrusted system. Password aging under trusted systems can do more precise math that untrusted because now the resolution is seconds rather than weeks.

[SAKERA PATEL]

TZ is GMT0BST

We are using the standard unix password database (i.e. just /etc/passwd)

[SAKERA PATEL]

Some other info which shows where I got those numbers from:

#define _PWD_DayNo(t) ((((t)/60)/60)/24)
#define _PWD_WeekNo(t) (_PWD_DayNo(t)/7)
#define WEEK (7*24*60*60)

time_t t = time(0);

printf("Time Now..: %ld %s", t, ctime(&t));
printf("Today.....: %ld\n", _PWD_DayNo(t));
printf("Week No...: %ld\n", _PWD_WeekNo(t));
printf("Week Start: %ld\n", _PWD_WeekNo(t)*7);
t = _PWD_WeekNo(t)*WEEK;
printf("Week Start: %ld %s", t, ctime(&t));
t += WEEK;
printf("Next Week : %ld %s", t, ctime(&t));
printf("\n");

[SAKERA PATEL]

One simple question is (regardless of what numbers I have presented) is if login should prompt for the new password on thursday or friday?

Because my testing has shown that it prompts for it on friday at 00:00

[A. Clay Stephenson]

Your math looks ok as long as you are not in Summer Time but I'm unsure of the behavior when minimum time between changes might also be 1 week. What is your minimum time between changes set to? It would also help if you posted a password entry along with what you think the time of last change was. Feel free to alter the password hash itself so no security is compromised but I would like to see the 4 aging characters in context.

[SAKERA PATEL]

Ok, I re-ran some of my tests as follows:

------------

Date: Thu Nov 3 12:01:15 GMT 2005
passwd -x 7 ; passwd mce2 (set to test)

/etc/passwd
mce2:DiC2SeJr6gI6k,/.CR:205:101:...

Date: Thu Nov 10 12:30:00 GMT 2005
Login as mce2/test (not prompted to change pw)

Date: Fri Nov 11 00:00:00 GMT 2005
Login as mce2/text (prompted to change PW)

------------

At this point I havn't touched the min days nor looked at what its set to. Repeating the above tests:

------------

Date: Thu Nov 3 12:00:00 GMT 2005
passwd -n 1 -x 7 mce2 ; passwd mce2

/etc/passwd
mce2:0kVuSObaQGXAE,//CR:205:101:Tes...

Date: Thu Nov 10 12:30:00 GMT 2005
Login as mce2 (not prompted for pw change)

Date: Fri Nov 11 00:00:00 GMT 2005
Login as mce2 (prompted to change password)

------------

These are just examples I have used as part of my testing into a problem our customers are reporting.

[SAKERA PATEL]

Another test I did starting on a tuesday instead:

-------

Date: Tue Nov 1 12:00:00 GMT 2005
# passwd -n 1 -x 7 mce2 ; passwd mce2

# grep mce2 /etc/passwd
mce2:nbzzN9gUKKwYw,//BR:205:101:Te...

Date: Thu Nov 3 12:00:00 GMT 2005
Login as mce2 (not prompted to change)

Date: Fri Nov 4 12:00:00 GMT 2005
Login as mce2 (prompted to change PW)

[A. Clay Stephenson]

Note that when you set the password on Tue, Nov 1 you got 'BR' => Week 1869 and when you set the password on Thur, Nov 3, you got 'CR' => Week 1870. This is exactly as expected and clearly indicates that a new week begins each Thursday. This is irrespective of when the last password change was made; the minimum resolution is 1 week beginning 00:00:00 UTC each Thursday (because the epoch date 1-Jan-1970 was a Thurday).

It's been many years since I have run an unshadowed or untrusted system but I do remember having to always issue new passwords on Thursdays because users would forget them or somehow fail to properly change them. I would expect that the system should prompt you for a new password each Thursday but note that users currently logged in could work with expired password and would not be logged off and thus would not actually be prompted for a password until the next time they actually login.

In any event, although I would expect the aging week to begin on Thursday, with a resolution of 1 week it hardly matters just so that it is consistant. Simply explain to your users that the resolution is 1 week and the system cannot tell if you actually changed the password on a Monday, Tuesday, ... because the resolution is one week.

When I was running NIS, I made my own login replacement and yppasswd relacement so that I could enforce strict password composition rules and shutdown logins after 3 attempts and I always started my new weeks on Thursdays since that is what the passwd(4) man page stipulates and is obviously correct given the 'BR' and 'CR' behavior you observed. It is possible that the login code does not exactly conform; you might look for login and passwd patches for 11.0 and try them but this doesn't seem to be too big of an issue although it is surprising. Frankly, I'm amazed that anyone is allowed to run plain, vanilla UNIX passwd's these days with the hash visible to anyone.

[SAKERA PATEL]

Thankyou for your input so far.

So you agree that it should be prompting (upon login) for the new password on thursday and not friday? i.e. its a bug in HPUX.

Its not as simple as telling the users to wait till friday to change their password. The problem is we have a PC client using a network service to authenticate. The authentication detects that the password has expired upon login on a thursday.

The users then login using a terminal session to change their password but are not prompted for one. Many users are not granted shell access to the machine, so the password change must be done by login. These users are left unable to login for a whole day.

What I need to understand is:

Is this a bug is HPUX?

Is there a patch to fix this bug?

Is this a bug in HPUX 11 only or in HPUX 10 also (I could test that).

Is this comon behaviour across most unixes?

I can work around this bug in my API, I will make the check add a day when on HPUX, I can also do this on any other platform I observe the same behaviour, but I dont like coding based on observered behaviour I would rather find the correct solution.

[SAKERA PATEL]

I will log a call with HP.