Yes I must agree on re-read I made two fatal mistakes. One should definitely
not pass encrypted tokens to the client and one should not design an
authentication scheme in the time takes to type out a message. Proper
approach would have been to replace steps 4 and 5 with this:
4. Send client a token to encrypt.
5. Check the returned encrypted token with encryption via the password on
the server side.
Thank you for staking me. I think this sounds a little bit more reasonable,
correct?
Bill
-----Original Message-----
From: Rich Salz [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 20, 2001 3:58 PM
To: [EMAIL PROTECTED]
Subject: Re: How can I encrypt public key in handshake?
> > 3. Verify that the server is who you think it is (via the public key)
> > (client can now trust server)
> > 4. Pass an encrypted token to the client (encrypted with client
password)
A classic, and amateur-level mistake. You should NEVER hand out
something encrypted with a user's password to anyone who asks. Cf.
KerberosIV. :) Using the steps above, the server is now quite
courteously helping an adversary with an off-line dictionary attack.
> This kind of ad hoc
> thinking by amateurs never results in a protocol worthy of deployment.
All too true. In fact, it usually results in protocols that should be
spiked through the heart but unfortunately escape, the undead, to
torment the truly security conscious.
/r$
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
