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.

The OpenSocial Hacks

So Google made a lot of news recently with their announcement of the OpenSocial API. The goal is to create a single set of APIs for application developers allowing them to build applications across multiple social networks such as Ning, LinkedIn, MySpace, Plaxo, etc. Tapping into the huge user base of these social networks with a single API should bring the time between application launch and having a significant user base down dramatically.

Since launching the API just a few days ago, there have already been 2 very public hacks of applications using it. The first hack was an application that launched on the Plaxo network and was hacked within 45 minutes. The hack was by no means malicious and committed by a self proclaimed amateur, TheHarmonyGuy. Here are the relevant stats from his blog:

Date: Friday, November 2, 2007

Initial hack: 45 minutes

Vulnerabilities:

• Able to change current Emote status for any user
• Able to access Emote history and current status for any user
• Able to insert HTML, including JavaScript, into Emote pages

Coverage: TechCrunch

Progress: Plaxo has removed Emote from their whitelist. As of Nov. 6, Emote remains unpatched.

He has just followed this up with another innocuous hack of a new application using the API on the Ning platform. TheHarmonyGuy was able to access the friends of Ning founder Marc Andreessen through the iLike application. And of course, the posted stats of the hack:

Date: November 5, 2007

Initial hack: 20 minutes

Vulnerabilities:

• Able to access listing of friends for any user and limited personal information about these friends
• Able to add and remove playlist tracks for any user

Coverage: TechCrunch

Progress: Ning and iLike have both been notified. Ning has replied and stated they are working to fix the issues ASAP.

Update: Confirmed that the first vulnerability is a Ning issue, not an iLike issue. More details here.

It’s great to see the coverage and attention these hacks are getting from the non-security crowd. As you can see from the stats TechCrunch has been giving TheHarmonyGuy a lot of attention. It reminds me a bit of the Adrian Lamo hacking events (here and here) of a few years ago. I am hoping the lessons learned from these public displays have a longer lasting affect than Adrian Lamo had. It seems clear there was a big rush to get some of this code out (although, it turns out, the second hack is more of an issue with Ning than OpenSocial) and some basic application security steps may have been skipped. Obviously this is not the first or last time for this.

Phishing 2.0

I have had several conversations recently about phishing, in particular spear phishing or social phishing. This is an example of how attacks have become much more targeted, and because of this, successful.

There was a study performed at the University of Indiana a little over a year ago on how spear phishing compared in success rate to that of blind or traditional phishing attacks. Within the paper they discuss the success rates of blind phishing attacks ranging anywhere between 3% (Gartner Group estimate) and 16% (blind attacks against the same or similar control group of the study). While this in itself is rather high when you consider the sheer volume of phishing attacks out there, it’s nothing compared to the success rate of spear phishing. Using the same control group within the University of Indiana experiment, the success rate of the spear phishing attack was a ridiculous 72%!

When you think about it, it makes a lot of sense. Messages have been bombarded into users why they should never click on a link in an email from someone they don’t know. But this is from someone they DO know. How many of us click on links sent to us via email or instant messenging by friends? Apparently 72% :-).

Now let’s combine this experiment in spear phishing with some cross site scripting (XSS) and cross site request forgery (CSRF) vulnerabilities out there to make it a bit more interesting. There have been a number of XSS vulnerabilities identified in some very large social networking sites recently. If we were to exploit one of these vulnerabilities, we could send our phishing site link to user X’s friends from user X. Assuming a success rate similar to that in the control group of the University of Indiana study (72%), we could end up with several million entries in our phishing database chock full of financial and personal data!

The fact is, this has already been successful on MySpace without nearly the malicious intent.

Phishing has become much more targeted recently, and one would presume much more successful. The proliferation of XSS and CSRF is staggering. Cross site scripting was listed as the most common vulnerability discovered in 2006, making up 21.5% of all new vulnerabilities. The popularity of web 2.0 and social networks continues to increase rapidly. This is a problem that will only become worse with all of these factors playing a part.