robert@peregrine.peregrine.com (Robert Young) (03/24/89)
I posted a question about three days ago regarding password aging. I think it got lost in the mail so here I am sending it again: We need to have password aging available in our DYNIX 3.0.12 system. I know thatthis feature is not available in 4.2BSD or related systems. System V has it though. If anyone has this feature implemented already I would appreaciate some pointers. I am already thinking of how to implement it but I am sure that someone out there has already though about it. In the meantime I will keep working at it. Hopefully, something will come back my way. Robert Young (Peregrine Systems )
gww@marduk.uucp (Gary Winiger) (03/30/89)
In article <38996@peregrine.peregrine.com> robert@peregrine.peregrine.com (Robert Young) writes: > >We need to have password aging available in our DYNIX 3.0.12 system. I know thatthis feature is not available in 4.2BSD or related systems. System V has it >though. You might wish to look at what Keith Bostic did at Berkeley. He's added password management software to 4.3BSD (Tahoe). I don't believe his modifications have been distributed on any BSD release, but should be available via FTP from him. The package is complete and self sufficient when applied to a 4.3 system. Give it a look, he's done a nice job. Gary..
fair@Apple.COM (Erik E. Fair) (04/06/89)
To answer the question: I have never seen a password aging system for 4BSD. However, it would not be that hard to implement - a daemon that can itself manipulate the password file (with the appropriate locking, etc), keeps track of when all the password cryptexts were last changed (dynamic discovery of new/deleted password entries too), and at the appropriate time, it changes the shell field to a temporary shell that forces a password change and changes the shell field back again to what the user usually has. This can all be done without changing /bin/login or /etc/getty. Meta comment: all password aging system implementations I have seen to date are EVIL. They surprise you one day without any warning and FORCE you to change your password on the spot to something else (and the "better" ones remember the last few you've used, so you can'y just cycle through a list). They're generally set to surprise you FAR too frequently. This causes people to pick VERY BAD PASSWORDS. Passwords that are easy to guess. Passwords that are english words, etc. People need time to think of good passwords, and perhaps some on-line tools for testing their potential passwords again the system's password policies. A GOOD password aging system would: 1) not allow the administrator to set a period LESS than six months (so I have to change my password only twice a year). 2) Give me a week's warning by Email, 7 days, 4 days, 2 days, and the day before it forced the change on me. Obviously, if I change my password in advance of this date, it would reset the time-changed so that I would not be bothered until the next period expired. 3) I can't think of a three right now. Doubtless, I will later... Erik E. Fair apple!fair fair@apple.com
hutch@rawfish.celerity (Jim Hutchison) (04/13/89)
This brings a question to mind. Do most peoples implementations of
get/putpwent() also handle their implementations of hashed/ghost/encrypted
password files? The daemon Erik suggested would seem to be fairly
straightforward if they do. The data base used by the daemon could easily
be a secure copy of the original password file with a date stuffed into
the GCOS field. It gets to periodically make a pass down the password file
looking for "languid", new, and deleted users, so not much reason for making
the database very fancy.
As to changing the shell, it is probably much easier to report them to the
authorities than to have the daemon writing into the password file, eh?
It's pretty pathetic to wait until the last minute to change your password, so
why bother with the user. Let individual sites decide how they abuse the
user for being a security hazard. A nice feature might be to make a smart
front end to passwd which would help users pick good passwords. Telling
the user what day their password times out, so they can put it on their
calendar would be nice. Oops, I've devolved into a builder of wish lists,
pardon. The gist of what I am trying to suggest is, report hazards and don't
take chances writing to the password file.
/* Jim Hutchison {dcdwest,ucbvax}!ucsd!celerity!hutch */
/* Disclaimor: I am not a official spokesman for FPS computing */