What is OpenID and why hasn’t it been setup correctly?
Tuesday, 27 March 2007
How it works
You place a tag on your blog/website which links to the OpenID server provider. Using this tag the OpenID server confirms that your blog should use authorisation through it’s service. So when you enter your blog into a OpenID enabled web site it will ask for your password on the OpenID provider’s service.
What do you mean it hasn’t been setup correctly?
Well the hole in this service is the fact that in the specification it allows you login to a web site without a password, how so you say? Well when you login to the OpenID provider you enter your password and it remembers it (caches it) allowing any web site in the world to possibly abuse this.
Huh? I want proof
Well I’m currently working on some more concept code to prove my theory but I’ve already produced an example that affected many OpenID providers.
http://janrain.com/blog/2007/03/22/myopenid-security-fix/
Why do you care?
I can see the OpenID service being very popular and therefore producing a huge security risk, I care because I don’t want a huge chunk of the internet exploited by the bad guys.
What’s your solution?
Easy! Ask for the password everytime a request to login to a web site is made. The OpenID provider needs to do this in order to prevent the attack above and also many other possible attacks. I want the OpenID specification to be changed to force OpenID providers to always ask for your password.
No. 1 — April 4th, 2007 at 5:26 pm
I don’t see your point, whether the password is remembered or not is up to the provider/user. Even better if the Server already recognizes me I won’t be tricked into some phishing attacks (other sites emulating my OpenID provider), because the browser takes care of recognizing my Provider. The less I send my password over the net the better. And by the way the OpenID standard says that I have to prove to my Provider that it’s actually me, and does not specify that this should be done using password, I could just as good use a public-private-key infrastructure.
No. 2 — April 11th, 2007 at 8:25 am
Well the point is that I think it would be possible for an attacker to force you to trust any site and also log onto any OpenID enabled web site. I don’t see how my point could be any stronger or clearer.
No. 3 — April 24th, 2007 at 8:59 pm
The thing is that most OpenID Providers provide a mechanism for you to choose which sites to trust and what information to disclose to a site. When I log in using my MyOpenID account to a site I’ve never visited before, I’m asked if I want to log in to it, and if they have requested a Nickname or Email, if I want to give it to them. After the first log in, the provider remembers my decision and forwards me directly.
I can revoke my decision whenever I want to.
No. 4 — April 25th, 2007 at 8:35 am
Ah yes but what if there is a problem with how that works? What if it was possible to automatically add that site to your “trusted” sites even though you’ve never visited it before.
I have already proved that once with MyOpenID and I have found other providers to have the same problems. The fact is if you don’t confirm a password on a site request, your OpenID service is less secure then if you did.
No. 5 — April 25th, 2007 at 9:03 am
To help you understand the problem I suggest you look into CSRF attacks [1]. The major problem is that an attacker could create a page that could automatically execute actions on your behalf.
Now some providers have provided protection against this and others haven’t, even the ones that have provided protection it could still be possible to perform the attack. I suggest any providers reading this also read my other blog posting on how to prevent these sort of attacks [2]
[1] http://en.wikipedia.org/wiki/Cross-site_request_forgery
[2] http://www.thespanner.co.uk/2007/04/12/one-time-form-tokens/