Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!rochester!ur-tut!ur-valhalla!moscom!jgp From: jgp@moscom.UUCP (Jim Prescott) Newsgroups: sci.crypt Subject: Re: Unix Password Security Message-ID: <1149@moscom.UUCP> Date: 3 Mar 88 03:53:01 GMT References: <7271@brl-smoke.ARPA> <5289@well.UUCP> Reply-To: jgp@moscom.UUCP (Jim Prescott) Distribution: na Organization: MOSCOM Corp, E. Rochester, NY Lines: 40 In article <5289@well.UUCP> pokey@well.UUCP (Jef Poskanzer) writes: >Ok, one fix would be to keep the encrypted passwords in a non-world-readable >file, while leaving the rest of /etc/passwd readable so that nothing breaks. AT&T's 386 Unix System V does this. /etc/shadow contains the encrypted password and some new info that provides useful capabilites, eg. it is possible to disable an account without messing with the password. Rather than have the password field be a random password or a '*' why not have it be a real password that the user can change. Programs that ask for your password to prove identity would still work but would use the "low security" password. Only login and su would deal with the "high security" password kept in the protected file. This would also make programs that prompt for your password slightly less of a bad idea. >Here's another idea. Change the password encryption algorithm so that >it runs through crypt a hundred times instead of once. And so that it Increasing the time taken to check a password is only a temporary solution. Machines keep getting faster. Brute force attacks are also trivial to run on multiple cpu's. A while back someone from Apollo said they had over 2000 machines on their network; being able to throw over 4000 MIPS at the problem will make short work of the hundredfold increase in processing time. In "Password Security: A Case History" they say one reason for the salt stuff Unix uses was to prevent the use of des chips which run several orders of magnitude faster than software. They add: "Obviously, the bad guy could have his own chip designed and built, but the cost would be unthinkable." Now I'm not a hardware type but I would guess that the cost of designing and implementing a "Unix des" chip is probably a lot less unthinkable now than in 1978. Does anyone have any rough idea of how hard/costly this would actually be? >doesn't take minutes to log in, use fdes instead of crypt. Yeah, that's What is fdes, a fast des algorithm? Could someone tell how to get a copy? -- Jim Prescott moscom!jgp@cs.rochester.edu {rutgers,ames,cmcl2}!rochester!moscom!jgp What the world needs now is a physical constant that differs from pi in only the hundredth decimal place.