Re: Adding a high-security channel for passwords -Reply

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 

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         

Received on Thursday, 8 August 1996 04:34:42 UTC