[dix] Re: Gathering requirements for in-browser OpenID support
Gabe Wachob
gabe.wachob at amsoft.net
Thu Oct 19 16:40:02 UTC 2006
And not to beat a dead horse to a pulp, but the Ph-Off Firefox extension
from OOTao provides exactly this sort of trustable (based on SSL certs)
visual indicator that you are actually talking to your real OpenID IDP. Its
obviously an early iteration, but it *is* there and performs the function
adequately.
http://chile.ootao.com/phoff/
-Gabe
> -----Original Message-----
> From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
> Behalf Of Chris Drake
> Sent: Thursday, October 19, 2006 9:35 AM
> To: Dick Hardt
> Cc: Digital Identity Exchange; general at openid.net
> Subject: Re[2]: [dix] Re: Gathering requirements for in-browser OpenID
> support
>
> Hi Dick,
>
> I disagree - the RP is *responsible* for directing the user to the
> IdP; This is the highest risk point of MITM attack. OpenID MUST
> include something to "enable" a "safe redirect" or browser-chrome
> activation or whathaveyou. Granted - chrome etc shouldn't be in the
> spec, but *enabling* it for the future MUST.
>
> Kind Regards,
> Chris Drake
>
>
> Thursday, October 19, 2006, 1:56:05 PM, you wrote:
>
> DH> The MITM attack vector resolution is out of scope of OpenID
> DH> Authentication as it is a ceremony between the user and the IdP. The
> DH> user and IdP need to know they are talking directly to each other.
>
> DH> -- Dick
>
> DH> On 18-Oct-06, at 1:07 PM, Scott Kveton wrote:
>
> >>> It is vulnerable to a man in the middle attack - the RP, instead of
> >>> redirecting to the IdP redirects to itself or some other site in
> >>> cahoots, then proxies the conversation between the user and the IdP
> >>> thereby compromising the users (global) credentials as they pass
> >>> through.
> >>
> >> Right, we've known about this for quite some time unfortunately
> >> there hasn't
> >> be a particularly easy solution to it and I classify this as one of
> >> those
> >> "The Internet Sucks" problems. I'm not saying we shouldn't/
> >> couldn't do
> >> anything about it I just think the right solution that mixes
> >> ease-of-implementation and user need hasn't been found yet.
> >>
> >>> There really needs to be user-agent support to avoid that - either
> >>> something CardSpace like, or browser plugin that only ever presents a
> >>> pre-authenticated user.
> >>
> >> I think we're headed in this direction. However, we have to crawl
> >> before we
> >> can walk. At least solving a big chunk of the use cases, getting some
> >> momentum behind the platform and solving a specific problem for users
> >> *today* is better than trying to build the perfect tool. We can
> >> talk and
> >> talk on these lists but we really don't know how users are going to
> >> use this
> >> stuff (or abuse it for that matter) until its out there and working
> >> in the
> >> wild.
> >>
> >> I can't emphasize more the fact that with every passing day that we
> >> don't
> >> have OpenID v2.0 out the door, we're losing momentum from fixing
> >> specific
> >> user problems that are solved in the existing specification.
> >>
> >> - Scott
> >>
> >> _______________________________________________
> >> general mailing list
> >> general at openid.net
> >> http://openid.net/mailman/listinfo/general
> >>
> >>
>
> DH> _______________________________________________
> DH> general mailing list
> DH> general at openid.net
> DH> http://openid.net/mailman/listinfo/general
>
>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
More information about the general
mailing list