Bill Browning wrote:
>
> 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?
Someone who eavesdrops can still brute-force the password. At the risk
of echoing others on the list, why are we trying to design a new, weak
challenge-response password protocol when established, strong ones that
resist these attacks are available?
corky peavy wrote:
>
> > This kind of ad hoc
> > thinking by amateurs never results in a protocol worthy of deployment.
> >
> > The whole concept of encrypting public keys is ludicrous, and it
> > doesn't matter what the answers are when you're asking the wrong
> > questions.
> > ______________________________________________________________________
> >
> Actually, I agree, but in the abscence of other solutions....
> If there is a well thought out solution, that would certianly serve the
> security requirement better. Is there such a thing, other than the drafts
> that are still just getting started?
If you're interested, you may want to participate in the SRP-in-TLS work
that's going on, both from a standards perspective (ietf-tls) and in
terms of helping out either with the existing Forge implementation or
with a proposed Open Source implementation in OpenSSL.
Tom
--
Tom Wu
Principal Software Engineer
Arcot Systems
(408) 969-6124
"The Borg? Sounds Swedish..."
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
