> 
> > I've been thinking of adding full SVID compatible password expiration to
> > NetBSD, though not necessarily SVID compliant (just tools to convert
> > SysV passwd/shadow file format entries, etc.).  This might make NetBSD a
> > teeny bit more attractive for current SysV users....
> > 
> > Is anyone else interested in this?
> 
> Yes and no.  
> 
> Having worked places where passwords were expired with ridiculous
> frequencey I'm not totally in favour of password ageing as it is
> often implemented or rather used.
> 
> One site expired passwords monthly, and then didn't let you change
> your password for a week!  So there you are in a _hurry_ to catch some
> program gone wild, forced to pick a new password (so you give it
> something flipant as you're already in a bad mood), then you can't
> go back and fix it.  Is this more secure?
> 

Yuck.  That is the kind of secure I expect to find at work; the kind
where the system is so secure NOONE can get on it.

> I do like though to be able to add users with a password that expires
> the first time they log in though.  (In Sysv I think it is just a ","
> at the end of the encrypted password).  I used to find that many users
> _never_ changed their password from the default one allocated to them.
> My super-dooper add_user script used to take care of that - if
> password ageing was supported.
> 

This would be workable from the current sources by setting the 'change'
date to today and the expire date to (say) three days.  While not being
a perfect solution, it would give you the kind of flexibility you are
looking for with a minimum of source turmoil.

> So yes used properly SysV style password aging is ok. However I
> believe the best method is to simply put a time stamp in each password
> record indicating when the password was changed.  You could then do a
> monthly cron job to mail all users who's passwords are n days old and
> ask them to change their password asap.  Any accounts with passwords
> n+grace days old are simply locked.
> 
> A look at the man pages suggests NetBSD already has a change and
> expire field in passwd though the usage is not quite as described
> above. 
> 

Actually, that is 'more or less' what my code does, except that you are
warned two weeks ahead instead of after the fact and you get a warning two 
weeks before your 'change' value from login instead of a warning from
a script.  Also, these are features from at least 4.3.  I remember
finding a bug in the expire code back during the 0.1 days that was
traced all the way back to the original Net/2 source.

Which brings us back to my original patch.  It gives you a long time
frame (six months in my code) and allows two weeks after the first
warnings to get your password changed.  No screaming or anything; just
change it at your leisure (or not at your peril).

> A quick look at login suggests that just about everything needed is
> there except a magic value to indicate you must change your password
> on first login. On seeing change == IMEDIATE_CHANGE, login could
> invoke passwd(1) and if it exits happily, proceed with login.

I thought about something like this once:  when the passwd expires, the
old password is used one last time, and a new passwd (through the
execution of a passwd like function) is generated and used.  The current
implementation is pretty stupid, though.  It allows you (as an example)
to use the same passwd over and over again.  Not much point in changing
the passwords if the user just repicks the same one over and over again.

> 
> I noticed too that su(1) does not support change or expire.  The
> change warning at least should be there as many folk don't allow root
> logins so no ageing would be enforced.
> 

I don't allow root to password age, for two reasons.  One - if you are
root, you deserve whatever you get if you don't regulary change the root
password and Two - the root password should always be available, no
matter how much time has passed, just in case there is a problem with
the password file and the users need to be let back in.

> And only root should be able to su to an expired account.
> 

Not that it makes much difference most of the time.  If their account is
expired and they have access to a second one, then they should be
allowed to su over there and fix their mistake.  We are talking about
adults (or reasonably detailed scale models, at least).