[security] [dix] Re: Gathering requirements for in-browser OpenID support

[Chris Drake]

Hi Ben,

For the benefit of me and others reading this thread, can you briefly
explain how you would deploy EKE in a browser to defeat MitM ?

Lets assume I set up a MitM site - https://www.paypal.com.phisher.com
and I even bother to buy a $38 SSL cert for it.  Next - I install a
CGI script here which grabs the real PayPal site, adjusts references
to paypal.com so they read "paypal.com.phisher.com" (eg: form POST
targets), and send this to the phish victim. *.phisher.com is now the
"Man in the Middle" between PayPal, and victim.

I call this a "stupid user" problem, because the user has forgotten to
check they're on the correct URL.  Everything else (except windows
password auto-complete) acts & looks legit.

Now - Encrypted Key Exchange solves this problem by: [insert your
explanation here] ?

Kind Regards,
Chris Drake


Monday, October 30, 2006, 10:05:11 PM, you wrote:

BL> On 28/10/06, Chris Drake <christopher at pobox.com> wrote:
>> Hi Ben,
>>
>> Apart from that blog where the blogger didn't realize that all banks
>> immediately suspend accounts that get logged in to from Russia,
>> Eastern Europe, Asia, and more generally - anyplace other than
>> "normal" - and as such - can't ever work - no - phishing attacks are
>> not MitM.  They're just bogus web sites that email captured
>> credentials to hackers.  Sure - some hackers might be able to capture
>> some token credentials, but they can't *use* them - not from Russia,
>> and not after the 30seconds or so most token codes last for.
>>
>> Besides - and the most important thing really - there's no such thing
>> that *I've* ever heard of that *can* be put into any protocol to
>> prevent MitM attacks from succeeding.  If user A doesn't check their
>> URL says site B when user A thinks they're on site C - then site B can
>> merely proxy anything site C puts up, stealing whatever they want in
>> the process.

BL> Clearly you need to update your crypto knowledge. There are many
BL> protocols that prevent MitM - for example, EKE.

BL> Yes, site B can always proxy, but it doesn't help site B if he is
BL> proxying a conversation he can't understand, by virtue of it being
BL> encrypted.

>> MitM is not a protocol problem - it's a "stupid user" problem.

BL> Wrong.

>>
>> Kind Regards,
>> Chris Drake
>>
>>
>> Sunday, October 29, 2006, 2:28:03 AM, you wrote:
>>
>> BL> On 28/10/06, Chris Drake <christopher at pobox.com> wrote:
>> >> BL> 2 factor auth gets you nowhere if the underlying protocols don't
>> >> BL> protect you from MitM.
>> >>
>> >> What he *means* of course - is that 2-Factor auth solves pretty much
>> >> every security problem users are likely to face in the wild
>> >> (especially the most common and dangerous - phishing) - with the
>> >> *exception* of Man-in-the-middle attacks, in some circumstances.
>>
>> BL> ? But many phishing attacks are MitM.
>>
>> >> It certainly doesn't "get you nowhere" - it almost always gets you
>> >> exactly to where you want to be.
>>
>> BL> We seem to be drifting far from the original point, which was that the
>> BL> protocols should protect users against MitM. 2-factor auth doesn't do
>> BL> this, of itself. And if the protocols do provide protection, then
>> BL> 2-factor auth defends against a rather small subset of attacks.
>>
>> >>
>> >> Kind Regards,
>> >> Chris Drake
>> >>
>> >>
>> >> _______________________________________________
>> >> general mailing list
>> >> general at openid.net
>> >> http://openid.net/mailman/listinfo/general
>> >>
>>
>>
>>
>>