chris@GYRE.UMD.EDU (Chris Torek) (11/07/88)
Be *very* careful how you implement password aging. If it is done improperly, it weakens security instead of strengthening it. For instance, if the system demands that you replace your password once every two weeks, and demands that you replace it immediately upon logging in, users are likely to use `easy' passwords and/or write them down, since they must remember them only for a short while and since they have little time to think of a new one. At any rate, we intend to implement shadow password files here (at U of MD CSD) if Berkeley does not get to it first. The way the worm breaks Unix passwords is by efficiently implementing the Unix `salted' DES encryption (possibly the worm's author simply used Bob Baldwin's code), and doing forward encryption on each of the passwords from its dictionary lists for each account. If the encrypted passwords are not readable except from privileged accounts, this method is not available; the program must instead go through standard accessways such as the `login' program, which were long ago instrumented to be able to log apparent breakin attempts. (Of course, all of this assumes that one is unable to exploit some existing bug that gives privileged access. It also assumes that your Unix vendor has at least kept up with Berkeley's security improvements since 4.2BSD.) We already enforce `hard to guess' passwords---dictionary checking is in 4.3BSD-tahoe, and we had been using similar checking earlier---and, by some stroke of luck, we had modified the finger daemon, and had a piggish sendmail: the worm gave it a mere 20 seconds to establish connections, and we no doubt timed out. At any rate, the worm never got established on any UMD CSD machine (though other departments were affected); but the potential was there, and that is rather frightening. The possibility of an efficient brute-force attack on other user's accounts, given an unprivileged account (as the finger bug did), is much more so. Shadow password files suddenly look quite attractive. . . . Chris
gww@SUN.COM (Gary Winiger) (11/10/88)
In article <8811070715.AA05179@gyre.umd.edu> chris@GYRE.UMD.EDU (Chris Torek) writes: > >At any rate, we intend to implement shadow password files here (at U of >MD CSD) if Berkeley does not get to it first. The way the worm breaks >Unix passwords is by efficiently implementing the Unix `salted' DES >encryption (possibly the worm's author simply used Bob Baldwin's code), > >We already enforce `hard to guess' passwords---dictionary checking is >in 4.3BSD-tahoe, and we had been using similar checking earlier---and, Chris, Some time in Jan, I posted a set of mods to 4.3 that I did while at ELXSI (with their permission) to implement shadow password files, password aging, and stronger password criteria. The were posted to alt.sources with a note in comp.bugs.4bsd. I also sent a copy to Keith Bostic. You may wish to look at that. If it doesn't meet you needs, it might serve as a starting point and illustrate a possible approach. If you'd like to get a copy, drop me a note and I'll return the shars by mail. Gary.. gww@Sun.COM P.S. I'll be traveling from 14 - 20 Nov. so replies won't happen until 21 Nov.
chk@dretor.dciem.dnd.ca (C. Harald Koch) (11/16/88)
In article <1988Nov8.224853.16081@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <6704@venera.isi.edu> cracraft@venera.isi.edu (Stuart Cracraft) writes: >>... If you enable aging, for example, once every >>month or two, every user who logs into your system will be required >>to specify a new password. > >On the spur of the moment, which means that he often will make up a poor >password, or simply alternate between two passwords. On a system somewhere that aged passwords at the beginning of each month, it was found that many users used the name of the month as their password to make it easy to remember. -chk -- C. Harald Koch NTT Systems, Inc., Toronto, Ontario chk@zorac.dciem.dnd.ca, chk@gpu.utcs.toronto.edu, chk@chk.mef.unicus.com Note: some sites may still have zorac.dciem.dnd.ca as zorac.ARPA. "I give you my phone number. If you worry, call me. I'll make you happy."
bzs@pinocchio.UUCP (Barry Shein) (11/18/88)
Although I support the other proposals I will argue that shadow password files are a bad idea (actually, I'm not too enamored with password aging, others have argued against this questionable idea.) It means that if, for any reason, you believe your password file has been let out you will have to admit that your security is compromised and, for starters, have everyone change their password (then spend your time "improving" the file's security etc.) You better also develop effective means of detecting whether anyone has read your password file or printed it out and not disposed of it properly. You're turning the file into pure gold. I still am confident that with methods like password changing programs which try to prod the user to choose a reasonable password AND education of users (perhaps backed with some internal enforcement, such as removing accounts that insist on trivial passwords, whatever your organization needs) the current publicly readable file affords MORE security than a shadow file. I sincerely hope that the community consider this matter before it becomes some sort of standard. I believe it compromises security by creating more problems than it solves, complicates security administration by requiring strict controls on who can access the file and creates new security crises when the file is believed to have been read by someone unauthorized. I fear that everyone is currently running willy-nilly trying to find *something* to do in response to this worm, let's not, in the heat of the moment, commit to something that actually makes matters worse. -Barry Shein, ||Encore||
slevy@UC.MSC.UMN.EDU ("Stuart Levy") (11/18/88)
> From: Barry Shein <encore!pinocchio!bzs@talcott.harvard.edu> > Although I support the other proposals I will argue that shadow > password files are a bad idea ... > It means that if, for any reason, you believe your password file has > been let out you will have to admit that your security is compromised > and, for starters, have everyone change their password ... > You're turning the file into pure gold. I don't understand this, could you explain further? Shadow password files aren't intended to contain clear passwords, they'd hold encrypted ones just as they do now. Using them would just impede people from casually picking up the file and trying passwords without going through login etc. But even if someone did capture a copy of a shadow pw file, you'd only be in the same situation you always were when /etc/passwd contained passwds. So is it really the kind of catastrophe you suggest? Stuart Levy
bzs@pinocchio.UUCP (Barry Shein) (11/19/88)
>> You're turning the file into pure gold. > >I don't understand this, could you explain further? Shadow password >files aren't intended to contain clear passwords, they'd hold encrypted >ones just as they do now. Using them would just impede people from casually >picking up the file and trying passwords without going through login etc. >But even if someone did capture a copy of a shadow pw file, you'd only be >in the same situation you always were when /etc/passwd contained passwds. >So is it really the kind of catastrophe you suggest? > > Stuart Levy That's the idealized situation. In reality once you've decided that the security of your system depends on the read security of one file then any breech of that must be responded to, common sense would dictate it. Otherwise, why did you make it unreadable? I don't think going forth with the idea "oh, we did it, but we never *really* needed to, it doesn't matter if a copy got out" is a rational approach. Otherwise one is just trying to have it both ways, relying on the security of an unreadable pw file but saying you don't really care if anyone reads it. At that point at best it's a matter of whether you can sell such an attitude to your (management? users?) when they come to you and say "gee, I saw so and so walk out with a listing of the password file...what are you going to do?" Don't think about yourself who knew in November 1988 *why* you went to shadow pw files, think about (oh) 5 years from now when every system is delivered and manuals say to keep the pw file unreadable because otherwise passwords might be cracked. I still contend it's a bad idea, concentrate on the other aspects. If some form of publicly readable encryption is deemed impossible as a concept I sincerely hope that argument gets published. -Barry Shein, ||Encore||
mckenney@distek4.uucp (Paul E. McKenney) (11/22/88)
In article <8811181901.AA12769@pinocchio.UUCP> bzs@pinocchio.UUCP (Barry Shein) writes (in regard to shadow password files): >>> You're turning the file into pure gold. >> [ . . . ] >>But even if someone did capture a copy of a shadow pw file, you'd only be >>in the same situation you always were when /etc/passwd contained passwds. >>So is it really the kind of catastrophe you suggest? >> Stuart Levy >That's the idealized situation. In reality once you've decided that >the security of your system depends on the read security of one file >then any breech of that must be responded to, common sense would >dictate it. Otherwise, why did you make it unreadable? I don't think >going forth with the idea "oh, we did it, but we never *really* needed >to, it doesn't matter if a copy got out" is a rational approach. > [ . . . ] >I still contend it's a bad idea, concentrate on the other aspects. >If some form of publicly readable encryption is deemed impossible >as a concept I sincerely hope that argument gets published. > -Barry Shein, ||Encore|| World-readable encrypted passwords allow an attacker to verify that he has correctly guessed a particular password, and to perform this verification on a host other than the one being attacked. This will allow the attacker to crack a significant fraction of the passwords (I have seen claims that over 30% of passwords are easily guessed) without leaving any traces of his attack, aside from a single (possibly legitimate) access to the system using the privileges of a normal user. Even if all passwords are well-chosen, the attacker has a non-zero chance of guessing a given password. If the attacker has enough fast hardware at his disposal, he may in fact have a pretty good chance. And there is always the chance that someone might come up with a clever attack on DES . . . Given a properly implemented and configured shadow password file, the attacker must have privileged access to the machine to get the encrypted passwords (assuming that all people that -do- have such know not to release the encrypted passwords). The attacker can of course use the target host's own login prompt to verify guesses at passwords, but this sort of activity should alert the host's administrators. If someone who does not have legitimate privileged access to the machine is seen with a list of the encrypted passwords, it can be assumed that the host's (network's) security has been compromised, and appropriate steps can be taken. It is still a good idea to encrypt the passwords (rather than relying solely on the filesystem permissions) in order to reduce vulnerability to the infamous ``disgruntled employee'' security hole. In short, the idea behind shadow password files is to make it at least as difficult to crack a password as it is to crack the system itself. This is an especially good idea for machines that have a password for the user ``root''. Thanx, Paul