Tuesday, April 21, 2009

Recent OpenID relying party vulnerabilities

The OSIS I5 OpenID interop testing is well underway.  Last weekend while testing some OpenID relying party web sites, John Bradley happened upon a web site that failed a particularly alarming test.  Further investigation revealed that the security hole affected all OpenID relying parties based on Janrain’s Ruby OpenID library.  Perhaps Janrain is using its Ruby library for RPXNow, because I discovered that RPXNow had the same security hole.

Janrain acted quickly.  They fixed RPXNow and released an update to the OpenID Ruby library within a day or so (version 2.1.5) after we reported the bugs to them. 

What does this mean for OpenID relying parties?  If you are using Janrain’s Ruby OpenID library (if you’re based on Ruby you probably are), make certain you are using the very new 2.1.5 version.  RPXNow customers don’t need to do anything as the patch was applied at the service.

Without going into the exploit details since there are still vulnerable relying parties that haven’t upgraded yet, let’s just say that this security hole was particularly devastating as it allowed a hacker to spoof anyone’s identity at the RP.  In English: “anyone could log in as anyone”.  Well, some basic knowledge of how OpenID works or and a hacker tool would be required. 

Aftermath

RPXNow customers as well as Ruby OpenID library users have been vulnerable, potentially for several months.  This means that if your site used RPXNow to allow OpenID logins, your users’ web accounts may have been hijacked, even if you haven’t heard any reports of it. 

If your site uses RPXNow or the Ruby OpenID library and stores private information for your users, you owe it to your users to notify them that their private data may have been compromised and/or their accounts/identity stolen.  Again, RPXNow has already been patched so in the future users will hopefully be safe, but the fix cannot be retroactive, and previously hijacked accounts are still victims.

I haven’t seen Janrain make any announcements regarding this security vulnerability.  I hope that in their private channels to their RPXNow and Ruby library customers they have advised them of the problem and that they should contact their respective customers to warn them of the potential loss of private data. 

I personally feel awful about this.  As neat as OpenID is, one of its weaknesses is that a user cannot be confident that an arbitrary RP he/she’s about to log into is a secure implementation of OpenID, and thus bugs like this can greatly reduce public trust in using OpenID to secure their identities.  But that’s why we do OSIS OpenID testing… to find and correct bugs like these.  I just wish we never found anything serious.

Thursday, April 16, 2009

DotNetOpenAuth 3.0 released

Download it now.

Previously named DotNetOpenId in its v1.x and 2.x releases, the v3.0 release is rechristened DotNetOpenAuth to reflect its support for multiple authentication and authorization protocols.  Sporting OpenID, OAuth and InfoCard support in its initial incarnation, it has been re-architected and largely rewritten to make adding more protocols fast and less error-prone.

Even if you’re already using DotNetOpenId 2.x and have no interest in InfoCard or OAuth, this is a worthy upgrade.  It’s faster, more stable, and better tested.  This new version is already being used as the standard for OSIS I5 OpenID interop testing, adding assurance that sites that use this library are secure and interoperate with many other sites and OpenID libraries.

In the making since August 30th, DotNetOpenAuth took 229 days to write.  Valued at nearly $1.9 million by Ohloh.net, this is truly the culmination of a lot of work of many developers and cryptography experts.  Although I wrote the library, I included some code from the Mono project for the Diffie-Hellman algorithm that OpenID requires.

  • New OAuth support! Both for Service Provider and Consumer roles.
  • RP+OP: discovery results cached for faster repeat logins (Issue 198).
  • RP+OP: Exceptions are now much more predictable: the host need only catch ProtocolException to handle all unexpected error cases.
  • RP+OP: OpenID extensions without simultaneous authentication (not that any such extensions exist).
  • RP+OP: Better interop with some remote servers that omit certain common HTTP headers.
  • RP: New InfoCard Selector ASP.NET control
  • RP: Classic ASP officially supported via our new COM server, including support for the Simple Registration extension.
  • RP: Signed callback arguments so relying parties can be confident their data was not tampered with during authentication.
  • RP: OpenIdAjaxTextBox now batches authentication attempts to several OPs specified in the user's XRDS document simultaneously in search of one that will authenticate without further user interaction.
  • RP: Smaller authentication request messages (shorter URLs).
  • RP: All callback arguments on return_to URL are now signed to protect against tampering (Issue 147).
  • RP: More reliable logins due to nonce checking that is per-provider endpoint instead of global (Issue 175).
  • RP: Added support for using ASP.NET State Server and other serialization-based session stores (Issue 185).
  • RP: More efficient reuse of allocated objects by ASP.NET controls.
  • OP: Ability to customize the lifetimes of each shared association type for added security.
  • OP: Even OpenID 1.x RPs are now protected from replay attacks on positive assertions (Issue 176).
  • OP: New ASP.NET MVC OpenID Provider sample.
  • 430+ unit tests (180+ more than DotNetOpenId 2.x).

Notes to web sites upgrading from DotNetOpenId 2.x:

The public API, while very similar, has changed its namespace. Hosting sites will need to accommodate to the changes!