robert@stevie.cs.unlv.edu (Robert Cray) (03/03/88)
In article <12035@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes: >It is interesting that people's ideas on security are often wrong. >For example, some people around here think that having different >passwords on different machines provides better security than >using the same one for all machines! It just ain't so. > But suppose you have an account on your machine, and an account on my machine. I modify login on my machine to record your password. I then try it on your machine. If all machines are administered by a single entity, you are of course correct. Also, supposed you have accounts on unix machines, where the password file is readable, and accounts on vms machines, where it is not. If your unix password is in websters, I can get it. Not so with vms, unless there is another security problem. Apparently I was wrong about vms 4.7 and remembered passwords, 4.7 is here, and it doesn't remember them. As many people have pointed out however, it would certainly be possible to impliment with no loss in security. VMS uses one of several encryption algorithms, using two salts, one of them random, and one based on the username. Thus if you copy the encrypted password from your account to mine, it won't work. What this gets you I have no idea. Remembering the last 6 passwords would only involve adding space to keep them in the password file, and encrypting the would-be password with each of the 6 salts and comparing the encrypted passwords. --robert
rbj@icst-cmr.arpa (Root Boy Jim) (03/09/88)
From: Robert Cray <robert@stevie.cs.unlv.EDU> In article <12035@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes: >It is interesting that people's ideas on security are often wrong. >For example, some people around here think that having different >passwords on different machines provides better security than >using the same one for all machines! It just ain't so. But suppose you have an account on your machine, and an account on my machine. I modify login on my machine to record your password. I then try it on your machine. If all machines are administered by a single entity, you are of course correct. Also, supposed you have accounts on unix machines, where the password file is readable, and accounts on vms machines, where it is not. If your unix password is in websters, I can get it. Not so with vms, unless there is another security problem. Evidently I left several premises unstated. First, I am talking about a BSD environment. Anyone who has accounts on more than one machine is likely to allow {rlogin,rsh,rcp} access to the other machines via .rhosts. In any event, the machines are host.equiv'ed anyway. Second, you do not have to go to such lengths to get my password. Just su to root, then su to whoever you want. Then rlogin anywhere a .rhosts file lets you. In short, if you allow access of this kind, you are also trusting the root person(s) on that machine. Given this environment, where one door opens them all, separate passwords just gives the attacker multiple targets. That was my point. --robert (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 Uh-oh -- WHY am I suddenly thinking of a VENERABLE religious leader frolicking on a FORT LAUDERDALE weekend?
mohamed@hscfvax.harvard.edu (Mohamed Ellozy) (09/27/88)
I have several questions to ask about passwords: 1. A few months ago there was a long discussion about choosing passwords. Has anyone archived that discussion? 2. Did the recent workshop on UNIX Security come to any conclusions about what is the minimal secure way to select a password? 3. Apparently System 5 Release 4 will finally hide the encrypted passwords. What is being done in this direction by various BSD implementations (both by UCB and by vendors)? 4. How successfully are they likely to be hidden in a networked environment? Will root on a client be able to get encrypted passwords? Thanks for any help. mohamed
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/12/91)
In article <26518@adm.brl.mil> JRAMSDEN%wl7.prime.com@relay.cs.net writes: > *But* if you then add a couple of numbers or a symbol, to make say > "Sch23wartzkopf" it gets converted immediately from being guessable > (at a pinch) to impossible. Someone might search for passwords where each character is 70% lowercase letter with Shannon frequencies, 10% uppercase letter, 15% digits 23457 (surely you know these are the most common?), 5% other digits. He'd get that password after, say, a hundred billion encryptions---around two months on a small Sun cluster. These are back-of-the-envelope estimates, but I certainly wouldn't say that password was impossible to guess. ---Dan
rickert@mp.cs.niu.edu (Neil Rickert) (04/12/91)
In article <14248:Apr1204:14:4891@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >Someone might search for passwords where each character is 70% lowercase >letter with Shannon frequencies, 10% uppercase letter, 15% digits 23457 >(surely you know these are the most common?), 5% other digits. He'd get >that password after, say, a hundred billion encryptions---around two >months on a small Sun cluster. These are back-of-the-envelope estimates, >but I certainly wouldn't say that password was impossible to guess. What I have never understood is why the password encryption algorithm doesn't use additional information other than the password - the user name and the machine name (or domain name for YP based networks). That way anyone who broke one encryption has succeeded only in breaking it for one user on one system. Sure, this would make life slightly tougher for administrators when propogating accounts to another host. But it would minimize the problem of someone using a supercomputer to derive a dictionary of encryption breakers for all common dictionary words. (The dictionary would have to be recomputed for each user on each machine). -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/13/91)
In article <1991Apr12.120209.21241@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > What I have never understood is why the password encryption algorithm doesn't > use additional information other than the password - the user name and the > machine name (or domain name for YP based networks). That way anyone who > broke one encryption has succeeded only in breaking it for one user on > one system. Sure, this would make life slightly tougher for administrators > when propogating accounts to another host. There's another reason, probably the more important one: if crypt() depends on the hostname and username, then somebody has to keep that information around and give it to crypt(). Since so many different programs use crypt() in so many different situations, this is (for all practical purposes) impossible. I advocate a *single* program to do *all* password checking. You give it a login name and a password on its input; it gives you a username on its output, or exits 1 with no output. If every use of crypt() were changed to use this program instead, it would be trivial to add features to increase security. But do you expect vendors to have enough foresight to take lasting modularity over short-term convenience? (By the way, kludging usernames into passwords doesn't really help except for stored-dictionary attacks. If the username is XORed in before encryption, you can break the password independently of the username. If the username is XORed in after encryption, it's pointless.) ---Dan
bennett@mp.cs.niu.edu (Scott Bennett) (04/14/91)
In article <17401:Apr1307:58:0691@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <1991Apr12.120209.21241@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >> What I have never understood is why the password encryption algorithm doesn't >> use additional information other than the password - the user name and the >> machine name (or domain name for YP based networks). That way anyone who >> broke one encryption has succeeded only in breaking it for one user on >> one system. Sure, this would make life slightly tougher for administrators >> when propogating accounts to another host. > >There's another reason, probably the more important one: if crypt() >depends on the hostname and username, then somebody has to keep that >information around and give it to crypt(). Since so many different Well, yes, things like login and rlogind and su would have to provide that information to crypt(). There may be a couple of others, but the quantity of programs involved would not be unmanageable, nor would the changes to those programs be particularly monumental. >programs use crypt() in so many different situations, this is (for all ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >practical purposes) impossible. > >I advocate a *single* program to do *all* password checking. You give it >a login name and a password on its input; it gives you a username on its >output, or exits 1 with no output. If every use of crypt() were changed >to use this program instead, it would be trivial to add features to ^^^^^^^ Possibly, but the vendors would probably be so busy fixing the rest of the programs (see your own reason that I underlined above) that broke when the changes were made that they would have few resources left to add the features. Neil has the right idea. >increase security. But do you expect vendors to have enough foresight to >take lasting modularity over short-term convenience? > >(By the way, kludging usernames into passwords doesn't really help >except for stored-dictionary attacks. If the username is XORed in before Where in the grid did you get the idea of XORing anything? Neil's posting certainly didn't say anything like that. >encryption, you can break the password independently of the username. If >the username is XORed in after encryption, it's pointless.) > >---Dan Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "Well, I don't know, but I've been told, in the heat of the sun * * a man died of cold..." Oakland, 19 Feb. 1991, first time since * * 25 Sept. 1970!!! Yippee!!!! Wondering what's NeXT... :-) * **********************************************************************
sidana@neon.Stanford.EDU (Ashmeet S Sidana) (04/15/91)
In article <17401:Apr1307:58:0691@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <1991Apr12.120209.21241@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >>What I have never understood is why the password encryption algorithm doesn't >> use additional information other than the password - the user name and the >> machine name (or domain name for YP based networks). That way anyone who >> broke one encryption has succeeded only in breaking it for one user on >> one system. Sure, this would make life slightly tougher for administrators >> when propogating accounts to another host. Ever tried changing the name of a host? You'd have to change all the passwords! I have a disk that boots two different versions of Unix with different hostnames. What a nightmare in that scheme! ---Ashmeet Sidana sidana@cs.stanford.edu
bzs@world.std.com (Barry Shein) (04/16/91)
Years ago I suggested on this list that vendors modify the password
algorithm so that at system installation a key could be entered which
perturbs its behavior on a per-machine basis (obviously a system admin
could choose to use the same key on every machine in an area so
password files could be shared.) This would frustrate the possibility
of someone on the outside picking up the encryptions and working on it
on another machine.
The hostname isn't a great idea because everyone knows the hostname.
I'd lean towards a key that was entered (possibly into NVRAM, tho
other schemes could be devised) when the system was installed.
From there on it would just be automatically used to encrypt tries.
Standardization is a wonderful thing, but perhaps some things just
shouldn't be so standardized.
--
-Barry Shein
Software Tool & Die | bzs@world.std.com | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD2004ktz@ucsbuxa.ucsb.edu (David G. Koontz) (04/17/91)
In article <BZS.91Apr15150237@world.std.com> bzs@world.std.com (Barry Shein) writes: >Years ago I suggested on this list that vendors modify the password >algorithm so that at system installation a key could be entered which >perturbs its behavior on a per-machine basis (obviously a system admin >could choose to use the same key on every machine in an area so >password files could be shared.) This would frustrate the possibility >of someone on the outside picking up the encryptions and working on it >on another machine. >The hostname isn't a great idea because everyone knows the hostname. >I'd lean towards a key that was entered (possibly into NVRAM, tho >other schemes could be devised) when the system was installed. >From there on it would just be automatically used to encrypt tries. >Standardization is a wonderful thing, but perhaps some things just >shouldn't be so standardized. It doesn't follow that having a secondary keying feature to differentiate password algorithms between different machines in the same community provides any security. Without enforcement a user is likely to use the same password on two different machines. With salting, as with a secondary keying feature, the password file entry passwd would more than likely be unique. Finding the password on any of the machines in a community would encourage the hacker to try that same plaintext (read source) password on another machine with the same user name. With the availability to the nonprivledged user of such commands as makekey or libcrypt (which is used by programs to verify access to a user by comparing the encrypted password entry to one supplied by the user and encrypted) make secondary keying variables such as using a non ZERO value for the initial data value in crypt(3) risky cryptographically. Imagine if you will that the identity for a crypt() call is the returned value for a NULL salt and NULL password. Even easier, a disassembler will tell you what the value is. Non public password files seem a better solution. They tend to be harder to get to, in general requiring a sys admin error. Sun Micros hidden password system requires root privledge to get a password entry (even your own). A public password file can be used for verification by a program not owned by root. It would be nice if the same password were not used in both.
chip@seeker.MYSTIC.COM (David "Chip" Reynolds) (04/19/91)
With all this talk about how to make fixed passwords more secure, I see, IMHO, a very criticle point being missed. First, a disclaimer: I am a programmer and a product manager for a Unix security package. I have some stake in what I'm posting here. If you want unbiased, junk this now. If you want to have accountability, or if you want to protect an account, fixed passwords just aren't the answer. If I do something on the system, there is NO WAY that a systems admin. can hold me accountable. "Someone stole my password! They must have hacked it! KGB spies are clearly responsible! The dog ate it!" take your pick. The only reasonable way to implement this is with a one-time password. Password Books, with one-use passwords can be stolen, photocopied, lost, etc. We use a different approach. It's called a "super-smart card." Using this card (we'll take one example, the MultiSync card. Which, incidentally is the only one so secure that the United States Government has put a secrecy order on disclosing the technology involved) the computer prompts you for an "ID:" you enter your id name, then it gives you a "Challange" which can be anumber of digits (numeric/hex/"friendly") that is variable on how the system is set-up from 4-32. YOu feed these into your card, and they are encrypted (a PIN can also be used as a salt, as can syncronizing the card with the system clock.) the card gives you back a response that you then re-enter. Using multiple DES keys, no to challanges are ever repeated (the card has a 23 digit cipher key, after the challange-responses have been used, you change the key) and the odds of guessing are in the area of 1 in 70 quadrillion. (assuming full installation.) UnixSafe (r) is installed in your /etc/passwd file as the shell for access, and it then allows you to define "On Access Granted" procedures. This is an out-and-out plug for the product, but I won't bore you further. If your interested, call/write me at my vitals below. The point of this post being: Fixed Passwords CAN'T work. Dynamic passwords are the only viable answer. Thanx, -*- DCKR -*- David Reynolds Blessed Be! chip@seeker.UUCP decwrl!prememos!chip@seeker.MYSTIC.com root@diana.UUCP David Reynolds Programmer, Product Manager UnixSafe/GatewaySafe Enigma Logic Inc. 2151 Salvio St. Suite 301 Concord Ca. 94520 (415) 827-5797
cs132041@cs.brown.edu (Jeremy Gaffney) (04/22/91)
In article <1071@seeker.MYSTIC.COM>, chip@seeker.MYSTIC.COM (David "Chip" Reynolds) writes: |> [Deleted text] |> If I do something on the system, there is NO WAY that a systems admin. can hold |> me accountable. "Someone stole my password! They must have hacked it! KGB |> spies are clearly responsible! The dog ate it!" take your pick. |> |> The only reasonable way to implement this is with a one-time password. |> |> Password Books, with one-use passwords can be stolen, photocopied, lost, etc. |> We use a different approach. It's called a "super-smart card." | [More deleted] |> system clock.) the card gives you back a response that you then re-enter. |> Using multiple DES keys, no to challanges are ever repeated (the card has a 23 |> digit cipher key, after the challange-responses have been used, you change the |> key) and the odds of guessing are in the area of 1 in 70 quadrillion. (assuming |> full installation.) |> What prevents this card from being stolen in the same fashion as a password book? If the user simply gives back what the card tells him/her, what prevents the card from being used by J. Q. Cracker who stole the card? Perhaps a pre-memorized function (albeit simple, by necessity) could be applied by the user, but at this point, the procedure is too complicated for any but the by necessity most secure system. Just far too complicated... -jg (cs132041@brownvm.brown.edu) |> -*- DCKR -*- David Reynolds |> Blessed Be! |> |> |> chip@seeker.UUCP |> decwrl!prememos!chip@seeker.MYSTIC.com |> |> root@diana.UUCP |> |> David Reynolds |> Programmer, Product Manager UnixSafe/GatewaySafe |> Enigma Logic Inc. |> 2151 Salvio St. Suite 301 |> Concord Ca. 94520 |> (415) 827-5797
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/25/91)
In article <1071@seeker.MYSTIC.COM> chip@seeker.MYSTIC.COM (David "Chip" Reynolds) writes: > If you want to have accountability, or if you want to protect an account, > fixed passwords just aren't the answer. [ ... ] > The point of this post being: Fixed Passwords CAN'T work. Dynamic passwords > are the only viable answer. No. There is nothing inherently wrong with fixed passwords. In fact, the smartcard that you mention does have a fixed password---it just doesn't tell anyone what that password is. If you're going to advertise a product on the net, you should at least stop confusing the issues. There *do* exist communications systems with dynamic passwords: both sides of a secure link must stay synchronized at all times, and there really is no fixed state. This is generally not appropriate for passwords. ---Dan