Dear OpenID Security Team: I've been working on an implementation of an OpenID 1.1 provider, and in so doing, have been analyzing the protocol in great detail.
On a straight reading of the specification, there would appear to be a significant vulnerability, which would allow any IDP to impersonate ANY OpenID identity. The scenario goes like this: 1. A rouge identity provider is setup (http://rogueidp.org/), and simply returns a positive assertion to ANY identity presented to it through check_immediate, check_setup or check_authentication. 2. I've chosen what OpenID identity I personally want to impersonate. John Smith has an OpenID identity at an identity provider (http://secureidp.org/jsmith). 3. I the attacker, setup my attacking OpenID page (http://attacker.org/attackjohn.html) with the following link relationships: openid.server = http://rogeidp.org/openid openid.delegate = http://secureid.org/jsmith 4. I go to John's favorite Wiki site, where he has authored a lot of content and developed a reputation using his OpenID identity. I can authenticate with the site just as he does, and impersonate him in all of my further deeds. </scenario> So, am I missing something? If I am correct in analysis, what recourse does the client (RP) have to ensure users cannot be impersonated? Or what recourse do users themselves have? Can client store and validate the server and delegates in its own user record? I don't think so because the OpenID spec explicitly allows users to change providers and yet preserve their identity. I suppose the least the provider can do is note that the IDP seems to have changed since last time, to alert the user that something is amiss, but this would merely inform the user his identity has been hijacked, with no ability to remedy. Thanks for any insight you can provide. Yours truly, Paul C. Bryan [EMAIL PROTECTED] _______________________________________________ security mailing list [email protected] http://openid.net/mailman/listinfo/security
