How secure is UNIX?

[Jonathan I. Kamens]

In article <11529 at vpk1.UUCP>, ram at attcan.UUCP (Richard Meesters) writes:
|> I'm not suggesting that we necessarily use the crypt() function call
ala UNIX
|> to provide the data encryption.  What I'm suggesting is that perhaps the ftp
|> code should include some form of encryption/decryption algorithm to protect
|> the password information.  IMHO, any plain-text password stored on a system 
|> is a security risk, no matter how well it is protected.

  It still won't work.  And, no offense intended, I still don't think
you've thought this through enough.  Before posting a suggestion like
this, try to through at least one concrete set-up which would make it
work properly.  Let me explain to you why I don't think you will be able to.

  You're proposing one of two things (I'm not sure which).  Either
you're saying that the password in the .netrc file should be encrypted
in a way that ftp or ftpd can decrypt, or you're saying that ftp should
encrypt the password before sending it over the network, and then ftpd
should decrypt it on the other end.

  In the former case, you must keep in mind that the ftp protocol is
publicly available, as is an implementation of ftp and ftpd.  If your
password in your .netrc is encrypted in a way that either ftp or ftpd
knows how to decrypt, then if I can read your .netrc, I can decrypt your
password by using the publicly available algorithm, or even easier by
using publicly available ftp/ftpd source code.  Therefore, you've gained
no security over the already existent security of not allowing other
users to read the .netrc file.

  In the latter case, once again, if I can read the encrypted password
in your .netrc file, then I can use the algorithm or the publicly
available ftpd code to decrypt it.  Furthermore, if I'm snooping on the
network and I see a password fly across the net encrypted in ftp's
encryption algorithm, then I know the algorithm to use to decrypt it. 
Therefore, once again, you haven't gained any security by implementing
encryption.

  Let's stop calling it encryption/decryption and call it the
"verification function.

  Now let's say that I make the verification function site-specific,
i.e. each site can define its on method of verifying that the password
info it gets proves that you are who you say you are.  You can make this
site-specific stuff either client-dependent or client-independent.  If
the former, then you've got to have a separate version of ftp for each
site.  This is impractical at best.  If the latter, you haven't gained
anything, because once again you have to send a password over the
network.  In fact, the client-independent solution is exactly what the
ftp protocol has now -- you send a password, and the server is allowed
to do anything it wants with it for verification.

  Even if you implement client-dependent two-part (one in the client,
one in the server) verification functions, once someone has managed to
read the client and your .netrc file, they can pretend to be you.  Once
again, the only security you've got is their inability to read those
files, which is pretty much no more security than there is now.

  Clearly, the strain running through all of this is the .netrc file --
delete that, and problems go away (well, most of them -- you still have
network snooping).

  If you make the assumptions that no one else can get your password
(i.e. either you never store it in a .netrc file or people really can't
read your .netrc file {hehehehehehe :-}), and that no one is snooping on
the network, then ftp is as secure as the normal Unix password scheme. 
*Think about* how Unix password security works, and then try to come up
with a concrete example of what you're proposing.

  Of course, if you don't assume that the network is secure, then you
need some network-secure authentication scheme, such as Kerberos.

|> Again, see above.  It doesn't have to be the same encryption algorithm that 
|> is used for /etc/passwd (or use the same key?).  So the password in 
|> /etc/passwd does not necessarily have any bearing on the passwd in .netrc.
|> The danger of a plain-text passwd in a file is that someone only has to SEE 
|> it, rather than necessarily decrypt it to be able to use it.

  It doesn't matter.  If I can read your .netrc, then I can decrypt the
password, since ftp knows how to decrypt it, and ftp sources are
publicly available (and the ftp binary is publicly executable on the
system).  Therefore, even encrypted, the security of the password
depends on the security of the .netrc file -- you're no better off than before.

  The reason Unix password security works is that the crypt() function
is a *trapdoor* function.  /bin/login doesn't say, "Let's decrypt the
password in /etc/passwd and see if it matches what the user says his
password is," because that's *impossible* (or, at least, it's believed
to be; I'm not sure if crypt() has been proven to be a trapdoor
function).  What /bin/login says is, "Let's take what the user says his
password is, encrypt it the same way the password was encrypted when it
was set, and see if what we get matches what's in the /etc/passwd file."
Then, if it matches, /bin/login gives the user appropriate privileges
*since /bin/login is a privileged program*.  Ftpd works the same way.

  What you're proposing is a two-way encryption function.  That doesn't
buy you anything, as long as files are not secure from unauthorized
reading, since what's in the file *is* the password.

  In effect, what you're proposing is a filter through which every
password must be passed before using it.  Anybody who can read your
password out of the .netrc can pass it through that filter as well as you can.

Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik at Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8495			      Home: 617-782-0710