Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!pprg.unm.edu!hc!lll-winken!uunet!seismo!esosun!cogen!celerity!rawfish!hutch
From: hutch@rawfish.celerity (Jim Hutchison)
Newsgroups: comp.sys.sequent,ca.unix
Subject: Re: Password Aging for 4.2BSD (or DYNIX )
Message-ID: <280@celerity.UUCP>
Date: 12 Apr 89 21:03:29 GMT
References: <38996@peregrine.peregrine.com> <28452@apple.Apple.COM>
Sender: news@celerity.UUCP
Reply-To: hutch@rawfish.UUCP (Jim Hutchison)
Distribution: usa
Organization: FPS Computing
Lines: 22

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    */