- From: Paul C. Kocher <pck@netcom.com>
- Date: Thu, 8 Aug 1996 01:34:29 -0700
- To: Baber_Amin@novell.com, ietf-tls@w3.org, pck@netcom.com
Baber Amin writes: > The idea sounds good, but if you offer good encryption for authnetication, > can we absolutely gaurentee that it would not be used for user data > other than pin or hashed password. > Do we even need to hash the password if it is being sent in a secure > fashion. Under my suggestion, the TLS protocol would allow virtually anything to go on the secure channel, but exportable implementations would have to limit the use of the secure encryption to meet government regulations. Passwords sent over the secure channel would normally be hashed so that the recipiant of the password does not get or need to know the actual password. (In practice, this hashing would probably consist of hashing just the password, followed by hashing with the client and server randoms.) This ensures that someone who compromises the server still has to brute-force the password. For something like a 4-digit ATM card PIN, the password needs to be sent in the clear and hashing the password is useless since brute force is trivial. This is why my note to the list I included both hashed and un-hashed passwords as things that might go over the secure channel. > How about a password based challenge responce mechanism to thwart > replay attacks. > i would aslo have questions regarding the shared secret that is > generated to send the password. How securely is the shared secret > master seed transmitted? Hashing with the randoms prevents replay attacks. The shared secret is already generated in SSL 3.0 (i.e., the Master_Secret), and would be used to generate these keys as well. -- Paul _____________________________________________________________________ Paul Kocher Voicemail: (415) 354-8004, FAX: (415) 321-1483 Cryptography consultant http://www.cryptography.com
Received on Thursday, 8 August 1996 04:34:42 UTC