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

[Ben Laurie]

On 19/10/06, Pete Rowley <prowley at redhat.com> wrote:
> Mike Glover wrote:
> > On Thu, 19 Oct 2006 18:52:01 +1000
> > Chris Drake  <christopher at pobox.com> wrote:
> >
> >
> >> SO - technology that takes AWAY from the RP the opportunity to
> >> initiate the OpenID login is a good way to safely prevent MITM
> >> attacks - the only thing that remains is to nut out exactly how we
> >> want to achieve this.
> >>
> >
> >
> > I'm not a security guy, so I'm hoping someone can help me understand.  How does this case differ from a generic phishing attack?  I understand that the mechanism and the stakes are different, but it seems that the problem is the same:  The end user goes to a page that they think they have an account with (in this case, the IdP), but it's really an attacker's site.
> >
> > Am I misunderstanding the attack here?
> >
> It is similar, but it relies upon the fact that the RP is the one doing
> the phishing, and that the user actually wants to login to the RP. Thus,
> every RP is a potential phisher. The page the user goes to will even
> look the same no matter which IdP they have since the RP knows which IdP
> to scrape.
>
> So all the clues tell the user they are at the right place except the
> url bar - and that is probably the least looked at thing in a browser
> for most people - especially when they don't know not to trust RPs,
> which they won't.
>
> Having the hooks that enable solutions to this outside the protocol is a
> MUST in my view. So, go Chris :)

Why not enable it inside the protocol? It isn't hard to ensure that
anything an RP gets is unusable anywhere else. Indeed, surely this is
a basic requirement for any secure SSO solution?

>
> --
> Pete
>
>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>
>
>