OpenID - A Security Story

Mon, 20 Aug 2007 10:15:48 GMT
by pdp

The other day Eugene Tsyrklevich has pinged me about his talk on OpenID security in regards to my article on Identity2.0 security issues that we face today. Eugene has presented an co-authored his research with Vlad Tsyrklevich at this year's BlackHat US. You can get the slides from over here and read the whitepaper from over there.

To summarize, the following issues are present with the current implementation of OpenID:

  • Phishing Attacks - this is probably the biggest concern when dealing with OpenID. Users may be tricked into providing their credentials to 3rd-party websites.
  • Man-in-the-middle Attacks - the connection is negotiated over DH (Diffie-Hellman) which is subjected to interception attacks. Ensure that you are using HTTPS.
  • Replay Attacks - the URL from the relaying party can be sniffed, unless over HTTPS, and as such being replayed. This is not that critical since if the attacker can sniff the wire(less) they can as easily wait for the authentication to complete and then steal the session identifier.
  • CSRF Attacks - once the user is logged in, attackers might be able to execute a series of CSRF (Cross-site request forgery) attacks against the identity provider or other sites where the user is logged in. "OpenID makes authentication easer so why don't we login everywhere?"
  • XSS Attacks - once the user is logged in attackers might be able to execute a series of XSS (Cross-site scripting) attacks against the identity provider, in which case they will be able to hijack the entire on-line use presence, or other sides, in which case the attacker will be able to gain access to the session. "Again, OpenID makes authentication easer so why don't we login everywhere, at the same time? Sounds like a good idea!"
  • Miscellaneous Attacks - all other types of Web Attacks are applicable to OpenID clients and servers. The only difference is that the result may turn to be quite nasty.

Other then that, OpenID is a great idea. It works and it scales quite well. However, make sure that you are protected against the above mentioned attacks. I would suggest for browser vendors to include builtin security features such as HTTPS should be enforced by default, CSRF against the identity provider domain should not be possible, etc. This can be accomplished with quite simple plugin for Firefox. Any takers?

Archived Comments

JordanJordan
I imagine a variant of this greasemonkey script would work: http://userscripts.org/scripts/show/1404 At least for forcing HTTPS. CSRF against identity provider domain requires a bit more thought. For example -- aren't the open id pictures stored on their domain? And surely we want to allow linking to the domain in general. Separating out which requests are potentially malicious CSRF would require all "action" urls to be obvious on the domain. To be honest, I haven't looked at Open ID yet to know whether that's the case.
Gareth HeyesGareth Heyes
I did a bit of OpenID security testing and I found many providers open to CSRF attacks. I found a exploit against MyOpenID and helped many others fix their problems. But I'm still not confident in OpenID security and providers need to up their game if it is to be ever considered for real world usage. My exploit can be found here, if anyone finds it interesting:- http://www.thespanner.co.uk/2007/06/29/openid-security-issues/
pdppdp
Jordan, yes preventing CSRF is not an easy task. I personally don't know how this can be secured at browser level. Therefore, we need to relay on the remote website being responsible enough to take the necessary actions. The script you've provided is good but I was thinking is for the browser having the ability to detect the OpenID provider and force it in there. Gareth, yes OpenID systems are full of CSRF today. It is not even funny. I don't know what developers were thinking when developing these systems. Thanks for the link.
Gareth HeyesGareth Heyes
@pdp CSRF can be secured with form tokens and random page names. If the attacker doesn't know what the script is called then he can't perform a CSRF.
pdppdp
Gareth, yes of course, but what I meant is preventing CSRF on browser level... otherwise we relay on the external site getting their security model right.
RonaldRonald
Indeed PDP, that is the biggest problem. Because the end-user is at risk here not the site owner persee. And I've pondered this question for a long time. Preventing it from happening in the browser is next to impossible. If we sitch to a different browser model we could potentially solve it. I have ideas, but they are only ideas. One of them is to sign all external content that is being requested. If it's unsigned it fails to load and thereby it prevents CSRF minimaly. The thing is, how do you sign it? if the browser must sign it, it must know the sites key. And there you have a key management problem. Another idea is to disallow any Javascript inclusion below the head tag -which is the toughest to control in case of an XSS- therby making sure all Javascript inclusions are only done in the head, and they may not be dymanically be altered: so signing them is an option. So I have a couple of hints & clues, no absolute awnser. There is a lot to be investigated in this area.
pdppdp
Ronald, I see what u mean. However, I would rather not start with certificates and stuff. It will make it too damn difficult to work it. I cannot see this happening. Moreover, Web2.0 mashups wont fit into tis model. There must be something else... or maybe not. Maybe the Web is just screwed up from day one and this is how it will remain forever.
mariomario
OpenID is not an authentication protocol. It is meant solely for homepage URL verification. It's not user-friendly and was never meant as generic login scheme for the web. It restricts itself to the technical experienced, so you can practically rule out phishing scams. The other security gaps might be troublesome, but hey, I see you are running Wordpress anyhow...