Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!rutgers!ucsd!hub.ucsb.edu!ucsbuxa!2004ktz From: 2004ktz@ucsbuxa.ucsb.edu (David G. Koontz) Newsgroups: comp.unix.wizards Subject: Re: Passwords Message-ID: <10614@hub.ucsb.edu> Date: 17 Apr 91 02:00:55 GMT References: <26518@adm.brl.mil> <14248: Apr1204: 14:4891@kramden.acf.nyu.edu> Sender: news@hub.ucsb.edu Lines: 49 In article 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.