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
arosen@hawk.ulowell.edu (MFHorn) (04/06/89)
In article <28452@apple.Apple.COM> fair@Apple.COM (Erik E. Fair) writes: > 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 VAX/VMS gives you a warning.. > 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. VMS tells you when you login "WARNING: Your password expires <date>". If you change it before that, the expiration date gets reset. But, it doesn't force you to change your password if you login after it's expired. If you logout without changing it yourself, you can't login again (without talking to your sys admin). In my opinion, this is worse than giving no warning. Disclaimer: I am by no means a fan of VMS. Unix (tm) rules. -- Andy Rosen | arosen@hawk.ulowell.edu | "I got this guitar and I ULowell, Box #3031 | ulowell!arosen | learned how to make it Lowell, Ma 01854 | | talk" -Thunder Road RD in '88 - The way it should've been
haynes@ucscc.UCSC.EDU (Jim Haynes) (04/07/89)
There is a shadow password package in one of the comp.something.sources
archives. I looked at it and it is rather Sys V oriented but could
probably be adapted into 4.2 without too much work. It includes password
aging, and if I understood it the aging is optional (you can set an
infinite expiration date, or at least one so far in the future that
it isn't likely to matter).
A shadow password package for 4.3 is in beta test now, and also includes
password aging, but that part isn't working yet, I'm told. I guess you
could say that it is for 4.4.
haynes@ucscc.ucsc.edu
haynes@ucscc.bitnet
..ucbvax!ucscc!haynes
"Any clod can have the facts, but having opinions is an Art."
Charles McCabe, San Francisco Chroniclepwolfe@kailand.KAI.COM (04/07/89)
> /* Written by arosen@hawk.ulowell.edu in kailand:comp.sys.sequent */ > VMS tells you when you login "WARNING: Your password expires <date>". > But, it doesn't force you to change your password if you login after > it's expired. If you logout without changing it yourself, you can't > login again (without talking to your sys admin). In my opinion, this > is worse than giving no warning. The best security system I've used was ACF2 on an IBM/MVS system (No flame wars, please!). ACF2 requires much less maintenance than VMS or, if you can call that security, UNIX. When your password was close to expiring, you got warnings, and if you didn't change it in time, the next time you tried to login it would prompt "Old password:", and "New password:". You couldn't login without changing it. Of course this meant you were forced to come up with something quickly on the fly (which usually means a bad choice), but that shouldn't stop you from picking a better one, and changing it again. Plus, ACF2 remembers every password you used within the past six months, and wouldn't let you repeat. I liked the VMS password generator. It would give you a list of 10 nonsense words built out of pronouncable syllables, and let you pick which one you wanted, or you could opt for another list of 10. I remember passwords better if I can pronounce them. On VMS, the system manager can setup someone's account so that they MUST use the password generator. Those who don't have this set can choose on the own to use it (SET PASSWORD/GENERATE=8 will pick passwords that are at least 8 characters long). Of course, ACF2 had a problem where a someone could "lock-out" another user by trying to guess their password three times. The account was then disabled until the division security manager re-enabled it. VMS only disables the account from logging in at the terminal where the break-in attempt occurred. But that's another story. Patrick Wolfe (pat@kai.com, {uunet,uiucuxc}!kailand!pat) System Manager, Kuck and Associates
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 */