[SecurityRatty] tag: openid

The nitty-gritty of information cards and OpenID interoperability

Sun, 31 Aug 2008 20:00:00 +0000

Sometimes an idea occurs simply because it's time for it to occur. It occurs to multiple people in multiple places at, roughly, the same time. Often those ideas, brilliant though they may be in their own right, are simply the extension of the ideas of others - a synthesis of many thoughts to arrive at a new conclusion. That appears to be happening in identity right now. The last two issues have talked about the grand unified theory of so-called "enterprise-centric" and "user-centric" identity. Now comes a paper talking about the interoperability of the two major user-centric models: information cards and OpenID.

Identity Heft: OpenID and What It Means for Web Security

Thu, 14 Aug 2008 13:16:22 +0000

User security on the Web is like the weather: it's a topic that generates plenty of talk but little meaningful action. Related Articles:...

An insecurity in OpenID, not many dead

Fri, 08 Aug 2008 21:33:39 +0000

Back in May it was realised that, thanks to an ill-advised change to some random number generation code, for over 18 months Debian systems had been generating crypto keys chosen from a set of 32,768 possibilities, rather than from billions and billions. Initial interest centred around the weakness of SSH keys, but in practice lots of different applications were at risk (see long list here).

In particular, SSL certificates (as used to identify https websites) might contain one of these weak keys — and so it would be possible for an attacker to successfully impersonate a secure website. Of course the attacker would need to persuade you to mistakenly visit their site — but it just so happens that one of the more devastating attacks on DNS has recently been discovered; so that’s not as unlikely as it must have seemed back in May.

Anyway, my old friend Ben Laurie (who is with Google these days) and I have been trawling the Internet to determine how many certificates there are containing these weak keys — and there’s a lot: around 1.5% of the certs we’ve examined.

But more of that another day! because earlier this week, Ben spotted that one of the weak certs was for Sun’s “OpenID” website, and that two more OpenID sites were weak as well (by weak we mean that a database lookup could reveal the private key!)

OpenID, for those who are unfamiliar with it, is a scheme for allowing you to prove your identity to site A (viz: provide your user name and password) and then use that identity on site B. There’s a queue of people offering the first bit, but rather less offering the second : because it means you rely on someone else’s due diligence in knowing who their users are — where “who” is a hard sort of thing to get your head around in an online environment.

The problem that Ben and I have identified (advisory here), is that an attacker can poison a DNS cache so it serves up the wrong IP address for openid.sun.com. Then, even if the victim is really cautious and uses https and checks the cert, their credentials can be phished. Thereafter, anyone who trusts Sun as an identity provider could be very disappointed. There’s other attacks as well, but you’ve probably got the general idea by now.

In principle Sun should make a replacement certificate and that should be it (and so they have — read Robin Wilton’s comments here). Except that they need to put the old certificate onto a Certificate Revocation List (CRL) because otherwise it will still be trusted from now until it expires (a fair while off). Sadly, many web browsers, and most of the OpenID codebases haven’t bothered with CRLs (or they don’t enable their checking by default so it’s as if it wasn’t there for most users).

One has to conclude that Sun (and the other two providers) should not be trusted by anyone for quite a while to come. But does that matter ? Since OpenID didn’t promise all that much anyway, does a serious flaw (which does require a certain amount of work to construct an attack) make any difference? At present this looks like the modern equivalent of a small earthquake in Chile.

SSO Summit Day One Morning Session

Thu, 24 Jul 2008 09:35:02 +0000

I am at the SSO Summit, high in the Colorado mountains (9200 feet elevation to be exact), the I-70 West sign is one of my favorite road signs. Ping Identity has done a great job putting this together. It is the perfect size around 125 people. Most of the best conferences I have been to have been around 60-150 people. There are a *lot* of enterprises involved here.

John Haggard who has an extensive background in SSO and lately is at Passfaces kicked off the sessions with a SSO history talk. Going through a lot of mainframe centric SSO protocols from the 80s and 90s, I am no expert in these areas and it was fascinating to see the way things vacillated between strength and weakness of SSO protocols.

A couple of points from the presentation:

The history of SSO is a story of extreme complexities, compromises, vulnerabilities and unintended consequences.

SSO is a story of one simple objective - to spin off units of computation work to execute on behalf of an authenticated user without requiring the original user's password.

Phishing has always been completely avoidable

He went through the various incarnations of mainframe SSO from logon id through things like ACF2, VTAM Session managers, terminal emulators, multiplatform access to web access through facades. The implication he drew from this last step are well worth repeating: "Time to rethink everything." Problem is - of course, people don't rethink, they put MQ Series in front of the mainframe and hook a web app in front of that and go.

Finally, he connected some interesting dots to SAML and SOA security issues.

SSO without strong auth is and always will be simply nuts

SAML gets its right

His points around common weaknesses in integration in SOA and Web 2.0 technologies for companies that are *not* using SAML were excellent. Of course, I will go into some more details on this tomorrow.

Ping's CTO Patrick Harding took the stage and gave an overview of the next generation of SSO options from Kerberos to present and as is his wont demonstrated various real world strengths and weaknesses, quoted a Gartner analyst (shock!) saying OpenID is the hare and Cardspace is the tortoise. Nice.

Andrew Cameron from GM is speaking now on GM's experiences implementing SSO, and there are a lot of real world lessons learned in his presentation. Plus my favorite identity architecture, user has Kerberos, services speak SAML. very nice, very scalable. All in all, its my starting point for how to identity in an enterprise. He also spoke about a pet peeve of mine - how to globalize authorization. This is not a problem that vendors have historically attacked with relish. They are very happy to help you solve authentication, but they are perfectly happy to keep their authorization internal either for vendor lock in reasons and/or for sloppy authorization design. This will take a LIberty-esque consortium of enterprises to resolve.

So many conferences are dominated by vendors and consultants who conspire to what I call the "sacred church of things YOU should be doing." Instead this conference is bringing together a great mix of real world in the trenches practitioners who have problems to solve today, with rubber meets the road deployable solutions and an eye towards longer term strategy for SSO and identity.

Notes from IEEE Web 2.0 Security and Privacy Workshop (W2SP2008)

Tue, 27 May 2008 18:45:00 +0000

Thursday 5/22 I was at the IEEE Web 2.0 Security and Privacy Workshop. I figured I'd learn a few things, and also make sure that no new exploits were announced against my employer, and/or make sure we weren't the only examples people gave of problems.

I was pretty successful on goal #1, not 100% successful on goal #2.

This post is mostly brain dump of notes about the talks followed by a few things of architectural interest that I think were discussed enough at the workshop. A quick preview - the first half of the conference was spent talking about general security holes in Web-1.0 that we still haven't solved technically/architecturally/culturally. With that in mind its hard to see how we're going to have much success with Web-2.0 security.

I'll start by saying though that I was ever so slightly disappointed with the makeup of the attendees. Conferences and workshops held by the IEEE and ACM do generally tend towards the seriously geeky and academic side of things. You're much more likely to find papers that are suitable for journals with plenty of academic references, peer review, CS technical terms, formulas, etc. At the same time though workshops do tend towards the less academic and more practical side. It was disappointing therefore that, though the workshop focused a lot of time on things like secure mashups, social networks, and Web-2.0 security models, to the best of my knowledge very few of the players in this space were present. I didn't meet anyone from any of the really interesting mashup companies and none of the social networks were there (minus google, who was well represented). Perhaps in the future people attending and organizing workshops like these can actually get the folks at the relevant companies interested, specifically invite them, etc.

Now, onto the papers/presentations themselves:

Session 1: Authentication and Authorization

Daniel Sandler and Dan S. Wallach. must die!
Daniel presented some good idea on how to move password authentication into the browser chrome to improve our defenses against javascript malware such as javascript keyloggers, etc.

While the work Daniel did was quite cool in that it doesn't require any protocol modifications, to be truly useful in implementing authentication inside browser chrome you probably need involvement from the site itself to hint, tweak, etc. Once you start doing that though, you start looking at doing stuff like cardspaces to actually get to a better architectural solution.

Ben Adida. Web Authentication by Email Address

Ben focused on usability concerns in OpenID and the idea that email addresses (or things that look like email addresses) are much better identifiers than URLs. He sketched out how to modify OpenID to use email addresses or lookalikes for authentication rather than URLs. Some of his proposals hinge on using DNS lookups for a domain to find the authentication server much like we use MX records for email. While potentially risky, DNSSEC could theoretically be used to mitigate some of the problems.

I must say I haven't kept up with OpenID as much as I'd like to, and so I'm 99% sure lots of the nuance of Ben's proposal was lost on me.

Session 2: Browser Security Models and Isolation

Collin Jackson and Adam Barth. Beware of Finer-Grained Origins

Collin Jackson presented some work he and Adam have done on how the browser security model, namely the same-origin policy, isn't nearly granular enough to handle most web applications and sites that host them.

For example:

http://cs.stanford.edu/~abarth
http://cs.stanford.edu/~cjackson

both have the same origin from the browsers point of view, but don't necessarily have the same security policy per use intent. Because the web browser can't really distinguish between them, we don't have a clean way of separating the security policies here.

Collin went on to show a multitude of problems in the same origin policy between sites, and problems in the upgrade/downgrade of security indicators in a browser. I won't rehash all of his results but suffice it to say we desperately need things like ForceHTTPS embeded in browsers in the near future to prevent some of these problems.

Kapil Singh and Wenke Lee. On the Design of a Web Browser: Lessons learned from Operating Systems

Kapil presented some research his team has been doing on modeling web browsers more like operating systems. You might have seen some related work recently as part of the OP Browser project. The idea is that the internal implementation of most browsers is pretty dicey from a security perspective. There is no clean separation between policy and mechanism. All code operates at the same privilege level. Plugins cannot be constrained in what they can do, etc.

I haven't seen any analysis yet comparing what MS did with IE7 on Vista in protected mode as compared to OP or Kapil's work. It is pretty clear that MS didn't fully segment IE7, but I wonder how close they got to ideal on the sandboxing side of things.

That said, I think our biggest problem in browser security isn't the implementation and internal segmentation. Our biggest problem is that we don't have any idea what security policies we really want to implement. Sure, having a flexible architecture under the hood makes it easier to implement flexible and finer-grained policies, but unless we have some idea what those are, perhaps we're putting the cart before the horse in terms of robust internal implementation.

Mike Ter Louw, Prithvi Bisht and V.N. Venkatakrishnan. Analysis of Hypertext Markup Isolation Techniques for XSS Prevention

My favorite presentation of the day was this one by Mike Ter Louw. Mike talked all about the multiple ideas circulating out there related to content restrictions. He showed the different failure modes for several of the proposals, showed how some of them can be rescued, and pointed towards areas that need more research.

The idea of content restrictions and server-indicated security policy that clients interpret and enforce is a really hot idea right now, and I'm hoping to catch up with Mike in the not too distant future.

Mike - if you see this, drop me a note :)

Session 3: Social Computing Privacy Issues

Adrienne Felt and David Evans. Privacy Protection for Social Networking Platform

Adrienne presented some work she's done on weaknesses in the security model of social networks and paltforms such as Facebook. She analyzed a bunch of Facebook applications to understand whether they really ought to be granted all of the rights over user data that they are. She proposed some mechanisms for limiting what types of applications get access to what data by enhancing the FBML tags to allow an application to get more data without API access. She also showed how you can solve some data sharing rules with just FBML and a few permissions extensions without resorting to full API access.

What Adrienne didn't come out and say is that in some contexts things like vetting are actually important. Most people in the social networking space and Web-2.0 space don't want to look at things like vetting, legal relationships, etc. as a model for achieving security. While a preventative model looks great on paper, solving some of the data safety/privacy concerns can really only be handled through contracts, vetting, etc. No amount of hoping developers will do the right thing and develop least-privilege applications will solve this problem.

Monica Chew, Dirk Balfanz, and Ben Laurie. (Under)mining Privacy in Social Networks

Monica presented some research on how we can inadvertently leak data from social networks by a multitude of means. While it was an interesting talk on how you can aggregate data from multiple locations to pin down more details than you ought to, since I'm not a heavy user of social networks I found myself less than interested in the general problem. If you're going to post large amounts of personal data online in multiple online sources, you're going to have people aggregating them together. There is only so much we can do to protect ourselves against that sort of aggregation.

Session 4: Mashups and Privacy

D. K. Smetters. Building Secure Mashups

D.K.'s talk was quite short on technical details and yet was one of the better talks of the day. Whereas I had a few complaints about Kapil's talk earlier in the day being a solution looking for a problem, D.K.'s talk was about the problem itself - namely - how do we actually define the security policy we're trying to achieve in the mashup space, what sorts of general rules ought to govern application behavior, security properties, etc.

This was the first talk of the day to really talk about user expectations for security, what we should generally understand to be user intent, and how to actually try and implement that in a mashup application.

Tyler Close. Web-key: Mashing with Permission

Tyler's talk may have been the most entertaining of the day, if only because of his obvious frustration with what the web has become. Tyler's main claim was that we ought to be using capability URLs to handle our authentication and authorization concerns. URLs that encode both authentication and authorization data bring us back to the original intent of the web, where the link is everything.

It was nice to see someone railing against a bit of what the web has become, but it almost felt like an original internet user lamenting the end of the end-to-end internet. A decent architectural argument, and yet one that isn't likely to yield a lot of converts. I don't think I understood a few of Tyler's points about how to prevent these URLs from leaking out and/or how to revoke access should they happen to. There are a multitude of user acceptance, behavior, and expectation questions to be answered. It was a nice twist though on how to perhaps make access-controlled content more in keeping with the spirit of the web.

Mihai Christodorescu. Private Use of Untrusted Web Servers via Opportunistic Encryption

Mihai's presentation was about how to take advantage of networked services/web-applications while proividing them with only opaque data references created with cryptography. His main example was about how to use Google's Calendar product without ever sending them your real data, and sending them only client-side encrypted data instead.

While it seems like a nice idea, and while parts of his solution were technically elegant, I think again it was a solution looking for a problem. If you're so concerned about a networked service having your data that you're willing to reverse engineer the service to make it store your individual data elements encrypted, then perhaps a networked service isn't the one for you. TYhe architectural challenges in achieving what he was able to with Google's calendar are nearly impossible with a more complicated service. And, in order to make it work you have to give up many of the feature's you'd really like from a service - full text searching, etc.

I'm guessing there are a few places where's Mihai's ideas are feasible, but its hard for me to see the value prop in building what he proposed.

Some Final Thoughts:

We haven't come close to solving the security problems in a Web-1.0 world
We don't know what the security policies really ought to look like for the web, consequently we don't know what the architecture and implementation look like either.
Browsers are lacking fundamental architecture and policy around security.
Web-2.0 only makes things worse

Apart from all of the unsolved security challenges, the biggest point that struck me from the workshop was the general belief (or I assume belief, I didn't challenge people on it) that mashups are here to stay, and that we're just going to have to back into a security model for them.

I remain unconvinced that a client-side application mashup between datasets is the only way to build new and innovative applications, and that if there were any liability concerns or even contracts that held some of these companies/services even semi-accountable, perhaps we'd have a very different architecture than we're seeing as part of the mashup space.

We're spending time and money working on specs like XDR, HTML5-access-control, and we still haven't solved some of the fundamental security problems of the web. I didn't see anything at this workshop to dissuade me from that perception either.

Its like the old saying goes - "If it ain't fixed - don't break it more". Well, ok, that isn't an old saying, but maybe a few of the people working on mashups and social networks could actually operate with that as their motto we'd make some progress on all of this.

The Venn of Identity: Options and Issues in Federated Identity Management

Thu, 22 May 2008 02:22:46 +0000

Digital identities can be associated with everything from people to software applications to entire companies, but human digital identities prove the most interesting and challenging. Human digital identities can simplify network usage and enable new classes of applications, but they also introduce security and privacy risks. Federated identity management addresses scenarios in both enterprise and consumer contexts by defining how to dynamically distribute identity information and delegate identity tasks across security domains. This article explains federated identity's components, discusses security and privacy risks and architectural challenges, surveys the SAML, OpenID, and InfoCard protocols, and reviews new developments in federated identity management.

Portable Identity and the BBC

Tue, 29 Apr 2008 10:30:00 +0000

We've spoken about OpenID before on this blog (see entries from 9 Feb 2008 and 7 Feb 2007) and I've been quite enthusiastic about the prospects for this "open, decentralized, free framework for user-centric digital identity." It seems that the BBC have seen the potential and joined the OpenID foundation. Jem Stone, on his blog, makes the bold statement that "getting identity right is key to our future plans." I couldn't agree more. Managing identity is central to the future and long term success of everything from social networking to eCommerce. For their part, the BBC are currently looking at the concept of "portable identity." Good job if they can make it happen - the trick will be in ensuring that the solution is safe to use on a home PC, public terminal, mobile phone and the myraid of other Internet enabled devices we're now being sold. Two factor authentication is a must but it needn't be based on clunky tokens. Any other out-of-band method will suffice, for example an SMS message with a one-time password on a mobile phone. Whatever the outcome, it's good to see my licence fee going on something that's innovative and, if successful, having wider benefits.

OpenID family grows How it can transform Identity Federation between enteprises

Thu, 07 Feb 2008 11:06:33 +0000

With Google, IBM, Microsoft, VeriSign, and Yahoo! joining the OpenID Foundation, we may actually feel that something in federated access management is going to change. It is finally not the case of a vendor proposing a new standard – and adding to the cacophony of federation standards – but a set of moves towards a simple technology that today can alleviate password management woes at service providers.

Technology aside, OpenID will greatly help with reducing and removing the legal obstacles in the way of identity federation’s proliferation. When payment-grade, commercial, and trusted identity provider service becomes a reality – VeriSign’s joining the OpenID camp clearly points in that direction – and software-as-a-service companies (like salesforce.com), accept OpenID authentication from these trusted identity providers, then enterprises can truly start thinking about outsourcing password management identity management processes. When required, strong authentication integration with OpenID can rely on VerSign’s VIP or other vendors’ strong authentication acceptance network.

In addition to the above factors, resolving DNS spoofing vulnerabilities and productized integration with SAML and other federation technologies will be key enablers in OpenID’s success and promotion from the current low-value (e.g. blogsite) authentication usage, to becoming a full-fledged, enterprise-level federation solution.

Major vendors join OpenID board

Wed, 06 Feb 2008 21:00:00 +0000

IBM, Google, Microsoft, Verisign and Yahoo have joined the corporate board of the OpenID Foundation, giving a boost to the group's efforts to simplify the process of signing into Web sites.

Fundamental Principles of Network Security	Advertisement
Protect the organization. Learn the 'Need To Know' aspects of network security. Free paper from APC.

Yahoo to support OpenID single sign-on

Wed, 16 Jan 2008 21:00:00 +0000

People with a Yahoo user name and password will be able to use that ID information to access non-Yahoo Web sites that support the OpenID 2.0 digital identity framework, reducing the amount of different logon information people need to create, remember and enter online.