OpenID Publishes Security Best Practices

A set of security best practices were recently published via wiki for users, providers, and relying parties of OpenID. Someone had recently asked me about a specific application that sits on top of OpenID and what I had thought of the security behind it. In the process of digging through it, I came across this newly developed Security Best Practices wiki.

Let me first apologize to my friend for getting a bit side-tracked off of his original question, but having written about OpenID about a year and a half ago, I felt the need to go through this and find out if any of the original concerns I had expressed had been addressed.

After going through the wiki, it’s mainly common sense security controls you would expect organized by audience for end users, OpenID providers and relying parties. That said, one thing really struck my eye:

“Relying Parties should not use OpenID Assertions to authorize transactions of monetary value if the assertion contains a PAPE message indicating that the user authenticated with Assurance Level NIST Level 0.”

This is big. Did I overlook these assurance levels contained within PAPE messages last year? I essentially had two gripes about OpenID, one being there are a lot of OpenID providers but not nearly enough relying parties (this is still the case IMHO), and two; setting up a relying party required you trust the authentication levels of the OpenID providers. While authentication control details are not revealed to the relying party (this is probably a good thing), this gives the relying party some level of assurance and the ability to pick and choose which OpenID providers they trust  to authenticate their users. I had previously complained that any site falling within a scope of a number of regulations wouldn’t really have the option of becoming a relying party, this may change that. As an example, if my application requires two factor authentication, as a relying party I know at a minimum the PAPE message must contain an Assurance Level of 3 or higher to meet my criteria. Here’s a link with more details to the various NIST assurance levels.

What do you think? Does this make OpenID more viable beyond the social media sites? Why? Why not?

UPDATE: Originally posted on CSOonline.

OpenID SSO Everywhere!

UPDATE: In TechCrunch this morning there’s a post about Microsoft accepting OpenID for their HealthVault beta. They note that Microsoft is only utilizing 2 OpenID providers, TrustBearer and Verisign for authentication. The reason, of course, is security.

Healthvault is obviously a product that will store highly sensitive information and will likely be regulated in some ways. This simply reaffirms my concerns in this post from February. As a relying party of OpenID, you do not have the insight in to what security measures are taken into account for authentication. Microsoft had to perform their own due diligence and then make a manual determination on which providers they would rely on.

Simon Willison says this is a good thing in his latest blog post here. While I somewhat agree, I think the adoption of OpenID would become greater if there was a more programmatic approach to this. As a relying party, I would not want to perform due diligence on every provider out there and then limit my users based on a point-in-time review. Read more below regarding my earlier thoughts this year on meta data. Could it be that my crystal ball is actually working? 🙂

Original Post ( 2/14/2008 ) Begins Here: Over the past few weeks OpenID has gained a lot of support and momentum from some very big sites. Last week the OpenID Foundation added Google, Microsoft, IBM, Verisign, and Yahoo! to its corporate board. A number of sites have come out supporting OpenID, mainly as identity providers. While it’s clear OpenID is getting a lot more support and use across the net, I would like to see more web applications ACCEPTING (relying party) OpenID. It seems much like the plethora of social sites cropping up on the web, everyone wants to be an identity provider and own the identity and profile data of the user.

So I’ve been meaning to dig deeper into OpenID for several months and write about my findings, but as usual my life had other priorities. After finally getting around to it, I must say I’m fairly impressed. Simon Willison has a great slidecast of his presentation last year at the Future Of Web Apps here. There were a number of ideas presented on various uses of OpenID that had not even crossed my mind. For those of you thinking OpenID = SSO (like the title of this entry), it’s so much more than that. I highly encourage you to watch the presentation.

That said, there are a few issues with OpenID. Some of them discussed by Simon at the end of his presentation.One that was not discussed that still bothers me is the lack of meta data about OpenID identity providers. One enhancement that I believe would really expand the use of OpenID across the web would be meta data associated with the identity provider. Right now, as a site that accepts OpenID, I have no ability to understand the authentication rules the user had to abide by with it’s identity provider.  While you may say, that’s up to the user to decide (and you’d be right, mostly), if I require a certain level of security for my web application for whatever reason, I would like to understand what rules the id provider made the user play by. Perhaps I am regulated on how my users authenticate to my application, this shouldn’t necessarily preclude me from accepting OpenID (it would today). If OpenID providers published meta data on the authentication rules, a site could then choose whether or not to accept the OpenID for authentication. Perhaps there could even be various security levels for OpenID providers (just thinking out loud). I could see an ecommerce site that stored additional sensitive information within a user profile to require a certain level of authentication rules from OpenID providers. Financial, trading, and tax sites would require even tighter rules.Right now the competition of the OpenID provider market should help. Users given a number of choices for providers can choose one that protects the user against phishing etc. (although given a choice, a user may choose a provider with less complex authentication rules).

Overall, OpenID is a really good idea, but I think it requires a few enhancements to expand its use beyond the social and email sites that seem to make up the majority of its use today. What do you think? Are you using OpenID today? I’d love to hear your thoughts in the comments section of this blog (which also acts as one of my OpenID’s, by the way) or send me an emal.