How secure is UNIX?

[Richard Meesters]

In article <1990Jun5.081053.25508 at athena.mit.edu>, jik at athena.mit.edu (Jonathan I. Kamens) writes:
< 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.
< 
<   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.
< 

Again, my thrust has really been that having a plain-text password in a file is
BAD (excuse the shout).  And the best possible thing to do is eliminate it.  
But if that's not possible, and a large number of users will most certainly 
balk at their administrators making life more miserable by making them (gasp!)
type passwords when they want to go across the network, then we need to provide
some level of security to the users, IMHO. 

<   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.
<   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.
< 

I agree that if you have access to the encryption function you can break the 
password/security of the system.  But it does buy you something.  What it gives
you is protection from the person who only gets a chance to _look_ at your 
.netrc/[file where password information is stored - this has in effect gone
beyond a specific topic] and see instantly what that password is.  At least 
with some level of encryption, someone will only see 'asfj8af2' instead of
'farpoint' or whatever you use as a password.  If anyone is dedicated enough,
or has access to enough information/source, he/she is likely to be able to 
break almost any protection scheme you can think of.  It's a matter of degree.

Regards,


------------------------------------------------------------------------------
     Richard A Meesters                |
     Technical Support Specialist      |     Insert std.logo here
     AT&T Canada                       |
                                       |     "Waste is a terrible thing
     ATTMAIL: ....attmail!rmeesters    |      to mind...clean up your act"
     UUCP:  ...att!attcan!ram          |
------------------------------------------------------------------------------