Re: Closing on shared-key authentication

Eric Murray sed:
> Marc VanHeyningen writes:
> > In other words, you're doing password authentication by just sending
> > the password encrypted, which Tom and I (and I suspect most other
> > people here) agree is not a very good way to do it.
> 
> Why not?

Lots of reasons; I'll mention a few.  

Because ciphers can be broken.  Because some people believe it's
unhygenic to have the security of authentication be dependent upon
the security of bulk encryption.

There are also simple usability concerns.  Users occasionally get
mixed up and, while using service A, accidentally type their
password for service B.  If you do things your way, you have just
given service A your password for service B, which is not
necessarily information you wanted him to have.  If you use a
challenge-based method, you have given him one specific
response to one specific challenge, which is of little if any
value as a tool for impersonating you in the future.

Persistent shared secrets shouldn't ever be sent in a reversibly
encrypted form unless there's no alternative.

> > No, another advantage is being able to use challenge-response
> > mechanisms based on passwords (or challenge-response 
> > mechanisms based on SecurID tokens or whatever) and not
> > requiring encryption at all (might encrypt it anyway, but the
> > security of it need not depend on that.)
> 
> If you don't require encryption why are you using TLS?
> (yea I know about the MAC-only ciphersuites, but they're not used
> in practice).

I trust HMAC-composed SHA-1 more than I trust 40-bit RC4, 
or even 128-bit RC4.  Don't you?

> There's other simpler protocols that implement challenge-response
> authentication, why not use one of those if that's all you want?

Are you referring to SASL, or what?

> Are we talking about the same things?  "just sending the password encrypted"
> to me means doing a complete TLS handshake and then sending the password
> as TLSed data, protected by the encryption/MAC negotiated by TLS.  Except for
> the problem of having to use 'export'-quality encryption to protect your
> authentication (which is an artifact of US government crypto policy and
> not a technical problem), I can't see anything wrong with it.
> So I must be misunderstanding the point that you're trying to make.

It means the password can be decrypted.  I prefer to only send my password
out in a fashion that cannot be decrypted, ever, by anyone.

- Marc

Received on Friday, 11 October 1996 18:54:04 UTC