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

[Alaric Dailey]

Trying to move this thread to security@


The only way a user could EVER be POSITIVELY sure that they are logging into
their IdP is something like WiKIDs mutual auth (
http://www.wikidsystems.com/technology/mutual_authentication/ ) short of
that, they have to trust the DNS and SSL that they see, AND that they typed
in the address they are going to rather than following a link or redirect. 

Bugs like these 2 could be used with cleverly crafted SSL certs to REALLY
pull off an almost perfect phishing attack, using any redirect without the
need to poison the DNS or modify a hosts file like a virus might.

http://secunia.com/advisories/10395/
http://www.theregister.com/2006/10/26/ie7_spoofing_bug/



As far as impossible MITM attacks? MITM attacks are difficult, there is no
doubt of that, BUT, unrealistic? No.  MITM attacks are how this happened...

http://blog.washingtonpost.com/securityfix/2006/07/citibank_phish_spoofs_2fa
ctor_1.html

Not only did this MITM attack WORK, but it works against 2 factor
authentication.

Weak user passwords is another problem entirely.

-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Ben Laurie
Sent: Thursday, October 26, 2006 10:26 AM
To: David Nicol
Cc: general at openid.net
Subject: Re: [dix] Re: Gathering requirements for in-browser OpenID support

On 20/10/06, David Nicol <davidnicol at gmail.com> wrote:
> On 10/20/06, Mike Glover <mpg4 at janrain.com> wrote:
>
> > Could you explain that some more?  Specifically, how would you prevent a
rogue RP from faking a redirect to the user's IdP (by proxying the request
instead)?  I can't see a way that the protocol itself can guard against
this.
> >
> > -mike
>
> I am sure there is a clear diagram somewhere within the POLA 
> literature about how to create unproxyable capabilities, and I expect 
> that picture describes a scheme where the capability is tied to the 
> originator in such a way that the MITM would be missing something 
> important.

You mean un-MitM-able capabilities. The holder of a capability can always
proxy it.

>
> of course, a protocol that is supposed to support users on NAT lans 
> has to support a MITM of sorts -- the NATing router -- so there are 
> immediately clear security/convenince tradeoffs.

? All protocols include many MitMs if you are going to call a NAT gateway
one - they're called "routers".

> Designing against theoretical MITM attacks can be impossible, since 
> theoretical men in the middle are so capable and flexible and have 
> unrealistic levels of access to infrastructure.

Its entirely possible. The usual weak link is users' crappy choice of
passwords.

>
>
> --
> The Country Of The Blind, by H.G. Wells 
> http://cronos.advenge.com/pc/Wells/p528.html
>
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general