How to stop future viruses.
Colin Plumb
w-colinp at microsoft.UUCP
Fri Nov 18 22:31:32 AEST 1988
In article <17575 at adm.BRL.MIL> rbj at 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 at sun.com)
More information about the Comp.unix.wizards
mailing list