Path: utzoo!attcan!uunet!snorkelwacker!bloom-beacon!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.questions
Subject: Re: How secure is UNIX?
Keywords: Security, ftp
Message-ID: <1990May29.124526.13935@athena.mit.edu>
Date: 29 May 90 12:45:26 GMT
References: <100928@<1990May23> <9000030@m.cs.uiuc.edu> <1990May28.102235.10021@agate.berkeley.edu> <6365@amelia.nas.nasa.gov> <1990May29.022854.22733@smsc.sony.com> <6368@amelia.nas.nasa.gov> <36584@ucbvax.BERKELEY.EDU>
Sender: news@athena.mit.edu (News system)
Reply-To: jik@athena.mit.edu (Jonathan I. Kamens)
Organization: Massachusetts Institute of Technology
Lines: 37

In article <36584@ucbvax.BERKELEY.EDU>, lauther@janus.Berkeley.EDU
(Ulrich Lauther) writes:
|> I just wonder why not the same technique is used with .netrc as with
|> /etc/passwd: have the file readable, but sensitive parts encrypted?

  Because this makes the .netrc file useless for its intended purpose.

  The .netrc file is meant to save you the effort of typing your
password when you ftp to another host, or to allow you to use ftp in a
shell script without you there to watch it.

  At some point, ftp has to be able to send your password in cleartext
over the network to the other host (that, in itself, is of course a
security hole, but what the hell, it isn't *too* painful to assume that
your network is secure :-).  An encrypted password simply isn't good enough.

  If the password in the .netrc file is encrypted with a one-way
encryption function, then there is no way to get the cleartext password
from the encrypted password string, so it's useless.  If it's encrypted
with a two-way function for which you provide the key when you do the
encryption, then it's still useless for unattended operation, since you
have to be there to type the encryption key to get it back.  If it's
encrypted with a two-way function with the key somewhere on-line, you
haven't gained anything, because anybody who can read your protected
.netrc can probably also read whereever the key is stored (i.e. you've
just introduced another layer of indirection without introducing any
added security).

  In comparison to the .netrc file, the reason that encrypting the
sensitive data in the /etc/passwd file works is that the OS never needs
to know your cleartext password, except when it prompts you for it (and
promptly does a crypt() on it and then throws the cleartext away).

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