Path: utzoo!attcan!uunet!husc6!rutgers!mailrus!cornell!uw-beaver!microsoft!w-colinp From: w-colinp@microsoft.UUCP (Colin Plumb) Newsgroups: comp.unix.wizards Subject: Re: How to stop future viruses. Message-ID: <31@microsoft.UUCP> Date: 18 Nov 88 12:31:32 GMT References: <17575@adm.BRL.MIL> Reply-To: w-colinp@microsoft.UUCP (Colin Plumb) Organization: Microsoft Corp., Redmond WA Lines: 76 Confusion: Microsoft Corp., Redmond WA In article <17575@adm.BRL.MIL> rbj@nav.icst.nbs.gov (Root Boy Jim) writes: >? /etc/shadow > >My first reaction is not to put it in /etc, or hide it with a dot, or >call it something weird, but that doesn't really accomplish much. This is correct. *Real* security assumes the attacker knows as much as you do about the system. >? Same as passwd, but only the username and password are filled in. >Why not fill it all in? Because the other stuff is supposed to be world-readable - why bother keeping a copy which nobody needs? And the update synchronisation problems... >? > what sort of stuff is left in the password field in /etc/passwd, > >? The letter 'x'. > >Here I disagree. It just announces the existence of the shadow file. >A better thing to do would be encrypt the password as usual, *and then >select a random salt* to replace the salt it was encrypted with. That >way, naive people can crack away to no avail. I repeat: security assumes the attacker knows as much as you do. This is what's fundamentally right about the existing Unix password system. The *only* piece of information it's possible to extract from the system is whether user "foo" has password "bar". This applies no matter what knowledge of privelege level you have. Putting extra barriers in the face of the naive doesn't increase your real security one bit, and does distract you from your main goal. Indeed, this is why I'm against the idea of a shadow password file. It is physically possible to get at it, and so only discourages weak attacks which probably wouldn't succeed anyway, providing a false sense of security. Getting a copy of /etc/shadow may involve breaking into the computer room and stealing some backup tapes, but more likely a good Unix hack knows half a dozen ways to get a copy of a root-readable-only file. A bug in some setuid-root utility not vhecking to see if the ruid has the proper permissions before printing/mailing/uucp-ing/whatever the file? As it stands, the only thing that's worth getting at that way are the system sources, which lots of people have already. What *I* want is the VAX to run them on - or the next-best thing, a password on somebody else's VAX. If we keep the password function sufficiently simple that it can be computed in a reasonable amount of time (1/4 sec?) on an 11/750 or similar wimpy machine, assuming I have a Sun/4 (10 times as fast?) and a week or two to spend at it, the only way to stop me from guessing passwords is to expand the search space to more than 4*60*60*24*15*10 = 51840000 passwords. This is more than the number of 5-letter lower-case passwords, although significanly less than the number of 6-letter ones. If you add mixed case and whatnot, you have more possible passwords than any brute-force attempt can hope to attack. A more selective search must come up with a list of "probable" passwords. If you make passwords fit some strange pattern that bears no resemblance to anything else (as I suggested in my last posting, strip off the first and last characters, and require the remaining ones to contain an upper-case letter, a lower-case letter, and a digit), neither the people picking the passwords or the cracker has anything the password "should" resemble, so there's no word list a cracker can use, and very little data to build one from. Remember: on a Unix system, most routes to a root shell don't involve knowing the root password. So don't assume someone with root priveleges doesn't need to crack passwords. Make it hard even for root. (P.S. Personally, I'm not keen on passwords. Hooray for Der Mouse! But there's no point in having the annoyances, and not the advantages, of a properly done system.) -- -Colin (microsof!w-colinp@sun.com)