Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!think!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: <1990Jun5.081053.25508@athena.mit.edu> Date: 5 Jun 90 08:10:53 GMT References: <100928@<1990May23> <9000030@m.cs.uiuc.edu> <1990Jun1.063800.17539@athena.mit.edu> <11529@vpk1.UUCP> Sender: news@athena.mit.edu (News system) Reply-To: jik@athena.mit.edu (Jonathan I. Kamens) Organization: Massachusetts Institute of Technology Lines: 105 In article <11529@vpk1.UUCP>, ram@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@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710