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

[Ben Laurie]

On 26/10/06, Alaric Dailey <alaricdailey at hotmail.com> wrote:
> 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.

2 factor auth gets you nowhere if the underlying protocols don't
protect you from MitM. This is exactly my point: protocols that do
protect you should be used.

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