sscott@camdev.UUCP (Steve Scott) (03/16/89)
Hello, netlanders....
As a major security overhaul within my company, the issue of password aging
has raised its head. So, I am in need of advice on how to implement such.
We have machines which are Sys V/BSD 4.x (HP/UX) compatible. We also have
Apollo machines running BSD4.2. I guess that I could write shell scripts
that "lock out" folks every ninety days and FORCE them to change passwords.
But I was wondering if any generic public domain solutions exixt
--
Steve Scott UUCP: {killer|texbell}!camdev!sscott
Motorola, Inc. Telephone : 1-817-232-6317ark@alice.UUCP (Andrew Koenig) (03/17/89)
In article <179@camdev.UUCP>, sscott@camdev.UUCP (Steve Scott) writes: > As a major security overhaul within my company, the issue of password aging > has raised its head. So, I am in need of advice on how to implement such. It is far from clear to me that password aging accomplishes much. Its usual effect is to cause people to toggle between two similar passwords. I don't believe for an instant that such toggling will make passwords any harder to guess, break, or acquire. On the other hand, it would be a real good idea to lock out any logins that aren't used in some sensible time period, like a month. -- --Andrew Koenig ark@europa.att.com
friedl@vsi.COM (Stephen J. Friedl) (03/18/89)
In article <9059@alice.UUCP>, ark@alice.UUCP (Andrew Koenig) writes: > It is far from clear to me that password aging accomplishes much. > Its usual effect is to cause people to toggle between two similar > passwords. I don't believe for an instant that such toggling > will make passwords any harder to guess, break, or acquire. Password aging makes it *much* easier to guess passwords. Not only do people tend to toggle between a two passwords, they toggle between two *bad* passwords because the timing is so terrible. There you are, sitting at your terminal, thinking about getting something done today. You enter your current password and SLAP, you can't do *anything* until you think of a password RIGHT NOW. This rude awakening is not conducive to picking a good password. Steve -- Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442 3B2-kind-of-guy / friedl@vsi.com / {attmail, uunet, etc}!vsi!friedl "I think, therefore I'm a yam." - me
levy@ttrdc.UUCP (Daniel R. Levy) (03/18/89)
In article <9059@alice.UUCP>, ark@alice.UUCP (Andrew Koenig) writes: < In article <179@camdev.UUCP>, sscott@camdev.UUCP (Steve Scott) writes: < < > As a major security overhaul within my company, the issue of password aging < > has raised its head. So, I am in need of advice on how to implement such. < < It is far from clear to me that password aging accomplishes much. < Its usual effect is to cause people to toggle between two similar < passwords. I don't believe for an instant that such toggling < will make passwords any harder to guess, break, or acquire. Toggling can be defeated by storing all past passwords for each user. -- Daniel R. Levy UNIX(R) mail: att!ttbcad!levy AT&T Bell Laboratories 5555 West Touhy Avenue Any opinions expressed in the message above are Skokie, Illinois 60077 mine, and not necessarily AT&T's.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/18/89)
In article <3275@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >Toggling can be defeated by storing all past passwords for each user. A cure worse than the disease.
gordon@sneaky.TANDY.COM (Gordon Burditt) (03/20/89)
Password aging doesn't have to be quite so detremental to password security as "SURPRISE! You have to pick a new password RIGHT NOW!". The solution to this problem is to provide a "checkpwage" program, which you encourage users to put in their .profile or .login files. (And new users should get a skeleton file that includes that.) The user should be able to specify how much advance warning of password expiration is wanted. The program would run silently unless the password was about to expire, then issue a warning like "Your password will expire at the end of Friday, April 3. Please change your password soon." Also, another option on "checkpwage" should let the user find out when the password expires at any time. (In systems not using shadow password files, this information is available anyway, but in a difficult-to-use form. "checkpwage" probably shouldn't make it convenient to find out when someone else's password is due to expire.) This will not completely eliminate the SURPRISE! problem. Since Sys V password aging is based on weeks, most users would want a 1-week warning, so if they don't log in for a week, they could get surprised. Users going on vacation could check before leaving, if they happen to think of it. This scheme will probably encourage users to switch between two carefully-thought-out passwords instead of switching between two hastily-made-up passwords. If you want to fix that, keep records of a few old passwords *IN ENCRYPTED FORM*, and don't allow re-use. I don't agree with a previous poster who claims that this is a cure worse than the disease. Encrypted passwords that don't work anyway aren't that much of a risk, and there is no reason to make them widely readable. This will encourage the user to switch between several passwords, probably the same password with a variable field for the month that changes each time. This might be slightly more secure than switching between two passwords. A few security-conscious users, hopefully including the administrator, might actually think up good passwords. The original poster said that "the issue of password aging had come up". This is a good description: password aging is much more of an issue than it is a solution to anything. Gordon L. Burditt ...!texbell!sneaky!gordon
whh@pbhya.PacBell.COM (Wilson Heydt) (03/21/89)
In article <8656@sneaky.TANDY.COM>, gordon@sneaky.TANDY.COM (Gordon Burditt) writes: > If you want to fix that, keep records of a few old passwords *IN ENCRYPTED > FORM*, and don't allow re-use. I don't agree with a previous poster who > claims that this is a cure worse than the disease. Encrypted passwords > that don't work anyway aren't that much of a risk, and there is no reason to > make them widely readable. This will encourage the user to switch between > several passwords, probably the same password with a variable field for the > month that changes each time. This might be slightly more secure than > switching between two passwords. A few security-conscious users, hopefully > including the administrator, might actually think up good passwords. The problem that this scheme presents is that: If the file of old passwords is broken, then the *pattern* of password picks for a given account may be discernable. While this is not useful for breaking the account of someone who picks really *good* passwords--effectively random--this is not the general case. If you doubt this, go read Kahn's "The Codebreakers" on the subject of Soviet one-time pads. ========================================================================= Hal Heydt | Money is the root of all Analyst, Pacific*Bell | evil--and a man *needs* 415-645-7708 | roots. whh@pbhya.PacBell.COM
pss@unh.UUCP (Paul S. Sawyer == paul) (03/21/89)
In article <3275@ttrdc.UUCP>, levy@ttrdc.UUCP (Daniel R. Levy) writes: > > Toggling can be defeated by storing all past passwords for each user. > -- > Daniel R. Levy UNIX(R) mail: att!ttbcad!levy > AT&T Bell Laboratories > 5555 West Touhy Avenue Any opinions expressed in the message above are > Skokie, Illinois 60077 mine, and not necessarily AT&T's. OK, assuming this is true, and assuming I have decided to do so, how do I implement this in my AT&T binary licensed System V, release 2.1.2? Is there a /etc/.passwdrc or such file for setting such an option? A tunable system parameter? ( add only 1/2 B-) (Yes, I DO know how to implement password aging, but I see it as Not a Good Thing...) At some time, in the NEAR future, binary licensees should be able to get source code for some of the *basic* utilities for which modification is needed to improve system security, beginning with /bin/login and /bin/passwd; I know that alternatives are available, but I would rather start with the "official" vendor supplied programs and take responsibility for any changes, than to guess as to whether a third party or self-written version of such a program is implemented "right" - we are dealing with setuid root programs, after all. I do not need, want, nor can we afford a complete source license... -- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Paul S. Sawyer uunet!unh!unhtel!paul paul@unhtel.UUCP UNH Telecommunications Durham, NH 03824-3523 VOX: 603-862-3262 FAX: 603-862-2030
ark@alice.UUCP (Andrew Koenig) (03/21/89)
In article <3275@ttrdc.UUCP>, levy@ttrdc.UUCP (Daniel R. Levy) writes: > Toggling can be defeated by storing all past passwords for each user. Yes indeed. Then the users have to tack a sequence number onto their passwords. Meanwhile it gets slower each time you change your password and there's a file sitting around that people would just love to steal. -- --Andrew Koenig ark@europa.att.com
jgn@nvuxr.UUCP (Joe Niederberger) (03/21/89)
In article <9059@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: >In article <179@camdev.UUCP>, sscott@camdev.UUCP (Steve Scott) writes: > >> As a major security overhaul within my company, the issue of password aging >> has raised its head. So, I am in need of advice on how to implement such. > >It is far from clear to me that password aging accomplishes much. >Its usual effect is to cause people to toggle between two similar >passwords. I don't believe for an instant that such toggling >will make passwords any harder to guess, break, or acquire. > It seems to me that the next logical step would be to force the user to invent totally new passwords (relative to his/herself of course) at each password change. But then, wouldn't the effect be to exacerbate the existing tendency of users to choose easily remembered passwords, which themselves present a security risk ? Does anybody have any statistical evidence that forcing password changes actually enhances security ? x x x x x x x x x x x x x x Joe Niederberger
dpw@lemuria.usi.com (Darryl P. Wagoner) (03/22/89)
This is really something that should be done in login(1) and passwd(1) commands. If you don't have a shadow password file then use a password aging file. I don't like time warnings as much as I do notices. ie: you have X logins to change your passwd otherwise login will forces you to change. There is also other games you can play like expire the password if more than X attempts have been made on that account. Or a password aging based upon the number of valid logins. You get the idea. The other thing that passwd(1) do is to check the passwd against a bad passwd file and gcos data then reject the passwd if it matches over X percent. As far as keeping a history of old passwords, that one is a hard call. I don't think that you would gain enough to make it worth while. -- Darryl Wagoner (home) dpw@lemuria.uucp or wagoner@imokay.dec.com Digital Equipment Corp; OS/2, Just say No! Boxboro, Ma (w) 508-264-5586 UUCP: virgin!lemuria!dpw
jay@hqda-ai.UUCP (Jay Heiser) (03/28/89)
I haven't seen any mention of it yet, but Kochan & Wood have an excellent text out called "UNIX System Security". Hardbound, its approx $35 & seems to be available in many computer bookstores. If your OS supports aging, then this is a must buy. When I inherited a 1000 user + Office Automation system, I also inherited approximately 500 identical passwords. They called it the 'default password'. It wasn't easy, but I talked them out of assigning those. I still have MANY group logins that are shared by OA innocents. Although that is ausdrucklich verboten, there isn't much I can do to catch it. Password aging works very well on both of those problems. System VR2 & VR3 force users to choose at least 6 chars, at least one of which is non-alpha, certain number of characters must differ from the old one, etc. Aging isn't permanent, but it appears to be the best solution for this site. Now, if OFFICEPOWER only supported it, we'd have something. (WARNING: many applications, such as CCI's OFFICEPOWER, not only don't support it, they defeat it. OP actually deletes the aging info for ALL users from the passwd file.)