Hello OpenID Security Community, This is my first post here, and before I get started, I'd like to compliment you all on the amazing progress that OpenID has made recently. As far as protocols go, this is very exciting, and I believe that it can be used as the foundation for as-yet unimagined new killerapps.
However, there are some severe phishing issues with the OpenID 2.0 draft specification which urgently need to be resolved before the draft is finalized. First of all, anyone can craft valid Auth Requests using spoofed values for openid.return_to and openid.realm. This has very nasty consequences for sites running redirect servers for click tracking purposes, such as these: http://x.go.com/cgi/x.pl?goto=http://www.jyte.com http://www.aol.com/ams/clickThruRedirect.adp?1,2,http://www.jyte.com A rogue RP could mask its identity and claim to be go.com or aol.com by hiding behind these redirect servers. When serving the Auth Request, an OP like myopenid.com will display this message to the user: "A site identifying as all sites matching http://anything.go.com has asked us for confirmation that xxxx is your identity URL..." This is EXTREMELY BAD, as users expect to trust their OP, especially if they feel extra secure because they configured an anti-phishing image (like MyOpenID's Personal Icon) and enabled SafeSignIn.This is particularly bad if the OP passes sensitive personal information or credentials via an extension in the Auth Response. The best way to resolve this issue is to define a way for the OP to verify that the return_to URL is actually a valid OpenID endpoint, and to also verify its association. I propose that an RP's return_to url expose an interface to allow it to identify itself as an OpenID 2.0 endpoint, and to also identify its association with the OP. Obviously, OPs must not follow redirects when interrogating the RP's endpoint. A possible interface would be for the RP return the its association handle if the OP hits the return_to url with the following parameters: openid.mode = "check_return_url" openid.server = "https://url_of_the_op.domain.com"; Instead of doing this on every Authentication Request, it would make sense for the OP to verify the RP as part of the association process. After the OP issues a shared secret and assoc_handle to the RP, the OP should be able to query the RP's return_to url before enabling the association, exactly the same way an RP can verify an Auth Response by querying the OP. Because this implies that an association should be tied to a given return_to url, the Association Request interface should be extended to require the return_to url. Once the OP has verified the return_to url, the OP can enable the association so that all incoming Auth Requests with that assoc_handle and return_to url can be served without requiring additional verification of the return_to url. Verifying that the return_to url is actually a valid OpenID endopoint prevents redirect servers from being used by phishers to spoof their identify. The additional step of tying an association with an RP's endpoint allows an OP a way to easily identify verified endpoints and realms, and allows a way for an RP to properly identify itself when making an Auth Request. I believe that resolving this issue would increase the level of trust that users place on their OPs, as currently, users cannot trust their OP to tell them what site they're logging into. My apologies for the long winded introductory mail. Comments and feedback would be very appreciated. Thanks, Allen _______________________________________________ security mailing list [email protected] http://openid.net/mailman/listinfo/security
