Date: Sat, 14 Aug 1999 14:35:34 -0700 (PDT) From: Kris Kennaway <kris@hub.freebsd.org> To: nsayer@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: Whither makefiles for src/crypto/telnet/* ? Message-ID: <Pine.BSF.4.10.9908141412020.45940-100000@hub.freebsd.org> In-Reply-To: <37B5D725.7916E60@quack.kfu.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 14 Aug 1999, Nick Sayer wrote: > > That's not the point, though - if you want to use legacy computer > > platforms, you have to expect to use legacy passwords. > > The point is that you can do so AND have an increase in security of > communications. Is the result perfect? No. Is it better than sending > it in the clear? Yes. Is it JUST AS EASY for everyone concerned as > sending it in the clear? Yes. So it's just as easy to do a little > as do nothing. Why, then, is it considered so horrible to have the > option of doing a little? Because the end-users won't understand this, and use the system as if it was perfect, when in fact it provides few guarantees. > > I haven't looked at > > the SRA algorithm, but it's not obvious to me how you can simultaneously > > provide a well-encrypted (against an attacker who is watching the setup > > phase) session, and at the same time only use the (traditional UNIX) > > password and hash. > > I would be happy to answer that. > > You do a traditional Diffie-Hellman. You use the resulting shared Where do you store the keys, or do you generate them dynamically? The latter would take time to verify primality. This is also essentially the way SSL does it, without some of the protocol overhead, and without trust verification of certificates. > secret to send the username and password from client to server, DES > encrypted. The resulting shared secret can also be used as a DES > (or other) key for session encryption after you're done. > > It is vulnerable to MiM. I have said as such a dozen times now. Yup. > It should be painfully obvious that plaintext sessions are vulnerable > to a hell of a lot more than just that. I agree. > > The server is configured at > > passwd(8) time. This is the beauty of SRP - it IS transparent, while at > > the same time being "secure" in the ways which a plaintext or CHAP > > authentication is not (I don't have references to the papers which > > describe the benefits of SRP handy, but I could find them if needed). > > I will easily conceed that SRP is more secure than SRA. But I disagree > that > it is as transparent as you claim. Because it does not interoperate with legacy servers over NIS? Any other reasons? > S/Key comes with FreeBSD. How many FreeBSD users use it? Never mind even > that, how many people reading this e-mail use it? One-time passwords have their own usability problems which make them not a general-purpose solution. > There are other costs, however. Your SRP equipped host cannot > participate in a heterogenous YP environment without maintaining SRP > passwords separately (and killing the purpose of YP in the process). > Even in a homogenous YP environment you have to synchronize valuse of > N and g (according to the Stanford web site) throughout the > organization. In my scheme I distribute these as part of the password "hash". N and g are both public values known to both client and server(s). I also have prototype code which can store multiple password hashes in the password file, and retrieves "secondaries" in a new field in struct passwd. You could conceivably set it up to keep a DES password in sync with the SRP one, and distribute only the DES over NIS. I don't know how extensible NIS is, but maybe we could hide the other hashes in there as well for those who understand them. > > Many would argue that in the language of cryptography and data > > encryption, the word "compromise" has only one meaning. > > So you would rather that plaintext be the only available option > that requires no overhead? How is anyone better served by that? > Why are you so opposed to an incremental step towards better security? No, I favour going directly for a strong solution. Inter-operation via NIS seems to be your only objection to SRP. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9908141412020.45940-100000>