Re: Closing on shared-key authentication

[Eric Murray <ericm@xxxxxxx>]

Marc VanHeyningen writes:
> 
> 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.  

[..]

Thanks.


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

Yep.  But I think 128-bit RC4 is "good enough" for passwords
that change oftener than every 40 years. (see schneier 2nd ed. pp 167).
40-bit, of course, is not.

 
> > 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.


So, to sum up the arguments for password auth in TLS, the reasons are:

1. 40-bit export ciphers are too weak to protect passwords.
With password auth, TLS could use stronger authentication-only
crypto to protect password material.

2. it's "unhygenic" to send passwords themselves, so apps should
send hashes of them, possibly including a challenge.  Since someone would
have to re-write existing password-based protocols to do this, it
should be placed in TLS, to make it easier to do. 


Any more?


-- 
Eric Murray  ericm@xxxxxxx  ericm@xxxxxxxxxxxxxx  http://www.lne.com/ericm
PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03  92 E8 AC E6 7E 27 29 AF