rbj@nav.icst.nbs.gov (Root Boy Jim) (11/28/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.) I agree with the latter, but not the former. I happen to believe that one should only choose *one* password *in their entire lifetime* and stick with it until one has reason to believe it has been compromised. The point being, that if you choose a different password, that you are providing multiple targets for the brute force approach. ? 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. Well, ain't it the (partial) truth? You seem to be saying that by ignoring the problem that no lapse of security exists. ? You're turning the file into pure gold. No, you're just moving the gold to a different place. And I see no reason why the shadow file has to become readable even by wizards. In spite of the recent holes exposed, and the possible ones that still exist, I believe that UNIX is intrinsically secure, or secure enuf. ? 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 think that both are necessary. ? 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. One other unmentioned benefit of shadow files: they allow you to rdist your password file across systems. ? 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. Good advice. True security is often elusive, and the obvious things to do are often wrong. ? -Barry Shein, ||Encore|| (Root Boy) Jim Cottrell (301) 975-5688 <rbj@nav.icst.nbs.gov> or <rbj@icst-cmr.arpa> Crackers and Worms -- Breakfast of Champions!
gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/29/88)
In article <17648@adm.BRL.MIL> rbj@nav.icst.nbs.gov (Root Boy Jim) writes: >I happen to believe that >one should only choose *one* password *in their entire lifetime* and >stick with it until one has reason to believe it has been compromised. This should be modified somewhat; so long as the same encryption scheme is being used, and the password is not thought to be vulnerable to the standard attacks, one is sufficient until it is compromised. However, it would be folly to use your well-protected UNIX password on a public BBS, for example, because very likely the password on the BBS is NOT so well protected, and once it is stolen there it could be used to enter your supposedly more secure system. I tend to use a single (different) password at each level of security, one for my accounts on public BBSes and the like, where I don't much care if it's compromised, and one for each type of protection (such as UNIX crypt()) on better-protected systems. In response to Barry's suggestion that shadow (really, non-public) password files are a panicky reaction to the Internet worm/virus: I've recommended this for years. AT&T adopted it for its MLS UNIX well before the virus scare. If done right, it adds a significant amount of security to the typical UNIX system. It's a good idea.
smb@ulysses.homer.nj.att.com (Steven M. Bellovin) (11/29/88)
The advantage of password-hiding is that it prevents fishing for passwords. That is, it establishes a difference between trying to crack my password (which I hope you can't do) and trying to find *any* password on a system.
friedl@vsi.COM (Stephen J. Friedl) (11/30/88)
In article <9001@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > > In response to Barry's suggestion that shadow (really, non-public) > password files are a panicky reaction to the Internet worm/virus: > I've recommended this for years. AT&T adopted it for its MLS UNIX > well before the virus scare. If done right, it adds a significant > amount of security to the typical UNIX system. It's a good idea. A good idea indeed. It does increase the complexity of the password code, but it can really foil a cracker. There are people out there (i.e., `me in a former life') who are fairly adept at converting an /etc/passwd file into a handful of logins given a couple of hours of processor time, a good list of sample passwords, and software to automate the task. Shadow passwords will cut this down in a pretty big way. How many of you have done 'grep :: /etc/passwd' on a machine? Steve -- Steve Friedl V-Systems, Inc. +1 714 545 6442 3B2-kind-of-guy friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl ---------Nancy Reagan on cutting the grass: "Just say mow"--------- :wq!
smb@ulysses.homer.nj.att.com (Steven M. Bellovin) (11/30/88)
In article <9001@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: } In article <17648@adm.BRL.MIL> rbj@nav.icst.nbs.gov (Root Boy Jim) writes: } >I happen to believe that } >one should only choose *one* password *in their entire lifetime* and } >stick with it until one has reason to believe it has been compromised. } } This should be modified somewhat; so long as the same encryption scheme } is being used, and the password is not thought to be vulnerable to the } standard attacks, one is sufficient until it is compromised. However, } it would be folly to use your well-protected UNIX password on a public } BBS, for example, because very likely the password on the BBS is NOT so } well protected, and once it is stolen there it could be used to enter } your supposedly more secure system. I tend to use a single (different) } password at each level of security, one for my accounts on public BBSes } and the like, where I don't much care if it's compromised, and one for } each type of protection (such as UNIX crypt()) on better-protected systems. Let me stress this further. One should also use different passwords for different authentication domains. I don't use the same password for my home machines as I do for other Bell Labs machines in other organizations. I'm guarding against several things, not just the cryptographic (or other) security of /etc/passwd, but also against boobytrapped login commands, etc. See the Grampp/Morris paper on UNIX system security for more details.
mchinni@ardec.arpa (Michael J. Chinni, SMCAR-CCS-E) (12/28/88)
F Y I
----- Forwarded message # 1:
Received: from [192.12.8.6] by ARDEC-CC1.ARDEC.ARPA id aa10257;
27 Dec 88 19:02 EST
Received: from [128.6.4.15] by IMD.PICA.ARMY.MIL id aa16810; 27 Dec 88 19:03 EST
Sender: security%pyrite.rutgers.edu@PICA.ARMY.MIL
Date: Wed, 14 Dec 88 15:40 EST
From: Lynn R Grant <Grant@DOCKMASTER.ARPA>
Subject: Password Aging
To: Security@RUTGERS.EDU
Message-ID: <8812271903.aa16810@IMD.PICA.ARMY.MIL>
Re: Bernie Cosell's question about the usefulness of password aging:
Password aging minimizes the amount of time that your password is open
to attack. You may have a well-chosen password, but the longer it is
used, the more likely it is that someone has looked over your shoulder
and seen you enter it, or a line-tapper has read it off your
communication line, or, if you are the type that writes your good
password on a piece of paper, someone has discovered it.
The DoD Password management guideline has another good use of this,
though I have never seen it implemented the way they describe. Most
systems I have seen will suspend your userid after you enter some number
of incorrect passwords. You must then get a security administrator to
reset it. This leaves you open to an easy denial-of-service attack.
And if someone does it to all your security administrators, the whole
shop is in trouble.
To counter this, the DoD guideline suggests making the logon process get
slower after the first few bad passwords are entered for a particular
userid. That limits how many passwords can be tried in a given length
of time, without leaving you open to the denial-of-service attack. If
you calculate how many trys it will take on the average to guess your
password, you can set up your password so it expires before then, making
a brute force attack much harder.
Lynn Grant
----- End of forwarded messagesbzs@Encore.COM (Barry Shein) (12/29/88)
Of course the obvious question is does anyone have any good cases of systems broken into where, if password aging had been in effect, the break-in would have been prevented? Reasoning appreciated. Other than cases like knowing full well a disgruntled employee has left (password aging assumes you don't know that something is under attack or has been compromised, I'm talking about automatic update, not any situation where if you had used your common sense and changed a password you would have avoided a problem because the password ager might not have kicked in yet in those cases either.) -Barry Shein, ||Encore||
smb@ulysses.homer.nj.att.com (Steven M. Bellovin) (12/29/88)
In article <4506@xenna.Encore.COM>, bzs@Encore.COM (Barry Shein) writes: > Of course the obvious question is does anyone have any good cases of > systems broken into where, if password aging had been in effect, the > break-in would have been prevented? Reasoning appreciated. The DoD reasoning is fairly simple: they want to prevent brute-force attacks on a particular password. I don't have their booklet handy, but they show you how to work through the calculations. Figure out how many possible passwords there are, and assume some value (which I believe they supply) for the time to make one trial. That gives you an upper bound on how long a particular password is secure. The aging constant is set to be some small fraction of that time. This is the same reasoning, of course, that leads the military to change codes and ciphers periodically. Read Kahn's ``The Codebreakers'' for examples of how this has helped, and how failure to do this has hurt.
bzs@Encore.COM (Barry Shein) (12/29/88)
From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin) >The DoD reasoning is fairly simple: they want to prevent brute-force >attacks on a particular password. I don't have their booklet handy, >but they show you how to work through the calculations. Figure out >how many possible passwords there are, and assume some value (which >I believe they supply) for the time to make one trial. That gives you >an upper bound on how long a particular password is secure. The aging >constant is set to be some small fraction of that time. We just did this, lessee, 100 character set, 8 chars, 100^8, assume 10,000 encryptions per second is a good upper bound (we'll take a small fraction in a moment) and, lessee, I get 31,709 years, divide by 100 (that's a small fraction, no?) I guess I age my password every 317 years, oh, what the hell, once per century just to be safe. -Barry Shein, ||Encore||
VINCE%UCONNVM.BITNET@mitvma.mit.edu (12/30/88)
Barry Shein writes: >We just did this, lessee, 100 character set, 8 chars, 100^8, assume >10,000 encryptions per second is a good upper bound (we'll take a >small fraction in a moment) and, lessee, I get 31,709 years, divide by >100 (that's a small fraction, no?) I guess I age my password every 317 >years, oh, what the hell, once per century just to be safe. But a 50 character set gives only 183 years, not 31,709, and if you really use only lower case letters plus a bit (30 chars) your 31,709 years becomes 2 years. Acknowledge-To: <VINCE@UCONNVM>
waters@dover.uucp (Mike Waters) (01/04/89)
In article <17986@adm.BRL.MIL> VINCE%UCONNVM.BITNET@mitvma.mit.edu writes: >Barry Shein writes: >>We just did this, lessee, 100 character set, 8 chars, 100^8, assume >>10,000 encryptions per second is a good upper bound (we'll take a . . . > >But a 50 character set gives only 183 years, not 31,709, and if you really >use only lower case letters plus a bit (30 chars) your 31,709 years >becomes 2 years. And if we use only easily remembered words it becomes as small as hours. In another thread here the author figures about 200K words > 5 char. long. Thats not very many to search if you can automate your search! Even using 10 words (50 char) gives a relatively small number. I think the problem is real, but I don't have any better solutions. -- Mike Waters AA4MW/7 * Motorola CAD Group * Witty remark goes *HERE* Mesa, AZ ...!sun!sunburn!dover!waters * OR moto@cad.Berkley.EDU *
jc@minya.UUCP (John Chambers) (01/08/89)
In article <4506@xenna.Encore.COM>, bzs@Encore.COM (Barry Shein) writes: > > Of course the obvious question is does anyone have any good cases of > systems broken into where, if password aging had been in effect, the > break-in would have been prevented? Reasoning appreciated. > Well, I don't know of any, but where I am currently working, there seems to be a case where password aging has decreased the general level of security. Why? Well, there's a lot of networking going on, and many people find themselves with accounts on 10 or 15 or 50 machines, each of which has to have a password. Password aging has been installed on some of them, so periodically users find themselves being harassed by yet another system that wants them to change their password. After a while, we all find that we have a whole lot of different passwords, and there's only one way that a mere human can possibly remember them: write them down on paper along with the hostnames. I have a list in the little pocket calendar that lives in my shirt pocket... Nuf said? -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) [Any errors in the above are due to failures in the logic of the keyboard, not in the fingers that did the typing.]
roth@macom1.UUCP (Dennis Paul Roth) (01/12/89)
From article <6@minya.UUCP>, by jc@minya.UUCP (John Chambers): > to change their password. After a while, we all find that we > have a whole lot of different passwords, and there's only one > way that a mere human can possibly remember them: write them > down on paper along with the hostnames. I have a list in the > little pocket calendar that lives in my shirt pocket... > > Nuf said? > > -- > John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) Ok, so you keep your passwords in your pocket, along with with your house, car, and office keys. Is the security of your house, car, and office compromised because you carry your keys in your pocket? That's all a password is, a key to your computer account. It is not the end all and be all of computer security. I think some of this discussion of password security in this newsgroup is going too far. People are trying to load too much of the overall security of computer systems on the password mechanism. Its just a lock and key. I've seen very, very secure computer systems with no passwords at all. If you need a lot of security, there are better methods than passwords. If you lose your slip of paper with your password on it you can change your password a lot easier than changing all the locks on your house if you lose your set of house keys. -- Dennis Roth ...grebyn!macom1!roth Centel Federal Systems roth@macom1.UUCP 11400 Commerce Park Drive Reston, VA 22091-1506 A posting a day keeps the boredom away. 703-758-7000
rickf@uts.amdahl.com (Rick Francis) (01/12/89)
In article <4783@macom1.UUCP> roth@macom1.UUCP (Dennis Paul Roth) writes: >From article <6@minya.UUCP>, by jc@minya.UUCP (John Chambers): >> >> Nuf said? > >Ok, so you keep your passwords in your pocket, along with with your >house, car, and office keys. Is the security of your house, car, and office >compromised because you carry your keys in your pocket? That's all a password >is, a key to your computer account. It is not the end all and be all of >computer security. I think some of this discussion of password security in > ... > ... >than passwords. If you lose your slip of paper with your password on it ^^^^^^^^^^^^^^^^^^^^^^^ >you can change your password a lot easier than changing all the locks on your >house if you lose your set of house keys. But there is a difference between a password and a key. If I get a quick look at your house key without your knowledge, the security of your house hasn't been compromised. But if I see the "key" to your computer account... -- ======================================================== Rick Francis rickf@uts.amdahl.com Amdahl Corp. {decwrl,sun,uunet}!amdahl!rickf ======================================================== [Amdahl's opinions are expressed by Amdahl, not me.]
roth@macom1.UUCP (Dennis Paul Roth) (01/13/89)
In article <edsJH550eM1010iOvbg@amdahl.uts.amdahl.com>, rickf@uts.amdahl.com (Rick Francis) writes: > > But there is a difference between a password and a key. If I get a > quick look at your house key without your knowledge, the security of > your house hasn't been compromised. But if I see the "key" to your > computer account... ... you've got to be one of the select few who will recognise the significance of what you've seen. Either you're an outsider trying to break into my system or and insider betraying the organization. One part of the security of my system has been compromised. I'll concede you that. But one of the points I've been trying to make is that computer security is more than just passwords. Now that you've seen my password you've got to get access to my computer. There's more to access control than just passwords. An insider already knows how access the system or can find out how. There is little or no defense against betrayal by those who have been trusted. We can punish those that we catch to deter others from doing the same. The outsider needs more than just a password to break a system where real security exists. The only thing you need to rob my house is the key to my front door and the only thing you need to get into some low security computers is a login and password. You need more than the key to the front door to rob The National Gallery of Art and you more than a password to get at a secure system. Security measures should be proportional to the value of whats being defended. Your original point was that if you give users a non-trivial password some dummies will write it down. I would like to add that if you give users trivial passwords some dummies will write them down. Further, no matter how the passwords are selected, some dummies will write their login and password on a piece of paper and tape it to their terminal. But, if you use non-trivial passwords you make it much harder for an outsider to get in. He's got to be damn lucky to get a peek at the piece of paper the careless user has written the password on and he has to know what he's seen. -- Dennis Roth ...grebyn!macom1!roth Centel Federal Systems roth@macom1.UUCP 11400 Commerce Park Drive Reston, VA 22091-1506 703-758-7000
dbf@pyramid.com (David Ferrier) (01/18/89)
>Password aging minimizes the amount of time that your password is open >to attack. You may have a well-chosen password, but the longer it is >used, the more likely it is that someone has [obtained it]... This sounds good, but no matter how they try to justify or explain it, password aging is one of those things that system administrators do that look really good to system administrators, auditors, and security consultants, but in practice does not give enough benefit to justify the tremendous inconvenience and loss of time caused to users and the organization. Security measures are put in place to prevent losses. If the cost over time of a security measure exceeds the probability of loss over time times the value of the assets, use of the security measure is bad management. Password aging is an example of a security measure, which, except for the CIA or other exceptional organizations, usually costs more to implement than the value of the assets protected. What does password aging buy you? -------------------------------- - it helps reduce risk by preventing access to the system and data by unauthorized users. Examination of past security incidents invariably shows that almost all damage done to systems or data was done by authorized users with passwords, not by the spooks that password aging is supposed to defend against. What are the risks of access by unauthorized users? ------------------------------------------------ - theft of machine cycles, unauthorized access to data, unauthorized modification or destruction of data. In most systems, the wastage of machine cycles by authorized users who are inexperienced or inefficient, or read dozens of USENET articles every day, far exceeds the possible cost of system use arising out of unauthorized access. As for data: signon passwords are only the first line of defense. Depending on the system, a user often has limited access to data. Unless unprotected data are not backed up, contain vital trade secrets, or there is no audit trail log generated of modifications to critical data, access by an unauthorized user is be much of a problem--not enough, anyway, to justify the cost of password aging. What is the objective improvement to security given by password aging? -------------- - who knows? How can you measure the likelyhood of a password being compromised when it is not changed regularly? A similar study might be done on people with wall safes who do not change the combination on a regular basis. What is the cost of password aging? ---------------------------------- - administrative: staffing a responsive corporate security department who can give out new passwords to users who tend to forget theirs when they have to change them regularly - user: need to build into project schedules enough slack to allow for loss of productivity due to being unable to access the system because a password has expired - organizational: replacing people who get fed up with the security run-around and leave Anything constructive to say about password aging? -------------------------------------------------- The following concepts came from working with a password aging system used by a Toronto computer utility that prevented reuse of any password for 20 cycles. Worse, it even prohibited use of near matches--"moon" and "fool" for example. Users had to keep a list of old passwords, because as a final diabolical twist, the system only gave you five tries to assign a valid new password when the old one expired, at which point use of your id was suspended. - If you must have password aging, keep it within reasonable bounds. As with any other corporate program, force the people proposing it to do a cost justification, and make a business case if they can for forcing people all over the company do regular password changes. - Make sure it is an option that you can control on an individual or departmental basis, so that only people with high risk data or extensive access rights are put to the inconvenience of changing passwords frequently, or at all. This control should extend to the number of generations of old passwords that are kept on file to ensure the new password does not replicate a previous password. -- David Ferrier Edmonton, Alberta alberta!myrias!dbf (403) 428 1616 [Moderator note: It looks like the upshot of this discussion is that aging isn't really much help... _H*]
martin@mwtech.UUCP (Martin Weitzel) (12/19/89)
In article <10680@attcan.UUCP> ram@attcan.UUCP (Richard Meesters) writes: [first part deleted] >All this is a wonderful way of thinking up a password, but what happens >when it comes to password aging? If you have to change your password as a [some more deleted] >I figure that how you set up your password schemes should depend on how much >security you want to build into your systems. On my personal systems, I dont >use, nor do I want to be forced to use, password aging. I don't think I have >any information that needs to be necessarily secured. Unfortunately, as you >increase the level of security, you are going to increase the difficulty of >accessing the system for your users. I just can't see any other way around >it. Password aging looks like a good idea - in the first place. If you look once again, it might only appeal to people, who care more about the formal aspects of their administrative work than about real system security. (Do I feel the flames here ...?) With password aging, this sort of administrator can allways tell (when someone breaks into the system): "... but I've set up password aging to 10 days, what more could I have done ..." The only "good" form of password aging is, to kindly remind the user, that his or her password has not changed for so and so long. All other forms - especially enforcing a new password, when someone is going to log in or out - tends to produce systems, which are *far less secure* than systems, where users are trained to be cooperative. This can be proven on many existing systems: In general "password guessing"- programs are far more succesful on systems with password aging turned on! If your user community is not too large and you have no remote logins, IMHO the most successfull approach is to go arround once a week, ask the people if there are any problems, how you (the system administrator) could eventually be helpful with any improvements, and *then* you may tell them: "By the way, it seems you are using the same password for six weeks now, how about a change?" -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
guy@auspex.auspex.com (Guy Harris) (06/23/90)
>(probably by someobody with a mixed BSD-SUN/ATT system >since BSD-SUN doesn't age passwords) ? While SunOS prior to 4.1 doesn't age passwords (regardless of whether you installed any of the S5 stuff or not, and regardless of whether you're using the S5 environment or not), SunOS 4.1 does permit you to age passwords (regardless of whether you installed any of the S5 stuff or not, and regardless of whether you're using the S5 environment or not). I don't know if anything was done to mesh this better with YP or not....
dcox@ssd.kodak.com (Don Cox) (03/12/91)
System type: Sun4/280, SunOS4.1.1
I am looking for a script that I can implement on my system that will
prompt the users to change their password every xx days. Thanks.
--
Don Cox
Phone (716) 253-7121 KMX (716) 253-7998
INTERNET dcox@ssd.kodak.commills@ccu.umanitoba.ca (Gary Mills) (03/12/91)
In <1991Mar11.185411.2414@ssd.kodak.com> dcox@ssd.kodak.com (Don Cox) writes: >System type: Sun4/280, SunOS4.1.1 >I am looking for a script that I can implement on my system that will >prompt the users to change their password every xx days. Thanks. SunOS 4.1 has this built in. See ``man passwd''. Unfortunately, ``yppasswd'' doesn't know about it, so users can't change their password remotely once password aging is enabled. Maybe it's fixed in 4.1.1? Is anyone using this? -- -Gary Mills- -Networking Group- -U of M Computer Services-