• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

Security

Page history last edited by sysadmin@shadowsinthegarden.com 14 years, 11 months ago

Reporting a Security Issue

If you believe you have found a security issue with the OpenID protocol, for the time being, please do this:

  1. Consult the list of Reported Security Issues whether your issue has been reported previously.
  2. If it appears to be a new issue, please send a test case that can be reproduced to the security@openid.net mailing list. Please state clearly:
    • which version of OpenID this applies to;
    • which implementations you have tested against it;
    • what benefits the attacker can obtain.
  3. The community will discuss the issue, and reach consensus on how to dispose the issue, such as:
    • issue is invalid;
    • issue is valid, but will not be fixed;
    • issue is valid, and needs a fix.
  4. A volunteer from the community will add the reported issue (whether valid or not) to the list of Reported Security Issues.

We expect to adapt/improve this process as the need arises in the future.

OpenID and Phishing

OpenID is more susceptible to phishing because malicious RPs can be easily set up to lure users into entering their authentication information at a web site that poses as the user's OP. The OpenID Phishing Brainstorm page contains ideas from recent discussions on the OpenID general mailing list.

OpenID and Cross-Site Request Forgery

This is a response to a blog post reporting a possible security problem with some OpenID servers. Essentially the problem is that by logging in with OpenID, one provides the information: that one is currently logged in to one's OP, along with the username. Malicious OpenID relying parties could use this information to submit forms to the OP utilizing the user's auth cookie, unbeknownst to the user. (using javascript to submit a form in an i-frame, or similar) Therefore web applications that serve as identity providers must be especially careful to protect the user's account.

To protect against this attack, commonly known as Cross-Site Request Forgery (abbreviated CSRF or XSRF), you must make sure that the form was served for the user and not for some attacker. One method is to check the referrer header on the form submission, but this may not be reliable, as some user agents may not provide this header. Another method is to put a hidden form element containing something based on a secret and data in the user's session object. Thus only a form served for a particular user will generate a submission valid for that user. Many reputable OpenID providers already use this method to secure form submissions, but it's the type of thing that smaller, less comprehensive implementations may neglect.

Found Security Practices in the Wild

Other resources

Here's a long list of threats to think about.

Considerations

return_to cannot be trusted (link)

3rd-party widgets (sourced outside the RP's site) endanger OpenID's privacy model (link)

Comments (1)

sysadmin@shadowsinthegarden.com said

at 5:54 pm on Apr 22, 2009

I've added "Considerations" after coming across something that wasn't an idea, but still shouldn't be forgotten. Perhaps a "best practices" security page should be added for what isn't a concern with the protocol itself (as currently implemented), but still a good thing to keep in mind?

You don't have permission to comment on this page.