Perimeter
10/8/2012
11:46 AM
Gunnar Peterson
Gunnar Peterson
Commentary
50%
50%

Infosec Slowly Puts Down Its Password Crystal Meth Pipe

Is Google's OAuth 2.0 implementation an identity plus or minus?

There is an immense amount of technology churn in identity. The Cloud Security Alliance guidance alone mentions dozens of different identity standards, but which ones work best for an enterprise, and how should it choose?

A pragmatic way to think about identity protocols is one part integration and one part security. Identity services enable distributed applications to work together, such that the service provider can recognize a valid request from a service consumer. This integration is not so useful if cannot be done securely, meaning that the protocol cannot simply propagate identity; it must provide a means to authenticate, authorize, and safely share attributes.

That combination of integration and security is what unites SAML, OAuth, XACML, and the like. The way the identity protocols achieve these goals is where you'll find differences.

OAuth's history is instructive. The history of this specification goes back to at least 2007 and OAuth 1.0:

"The OAuth protocol enables websites or applications (Consumers) to access Protected Resources from a Web service (Service Provider) via an API, without requiring Users to disclose their Service Provider credentials to the Consumers. More generally, OAuth creates a freely-implementable and generic methodology for API authentication.

An example use case is allowing printing service printer.example.com (the Consumer), to access private photos stored on photos.example.net (the Service Provider) without requiring Users to provide their photos.example.net credentials to printer.example.com."

The value of an open standard that enables the above has clear benefits for integration. But the protocol's utility is predicated on being able to integrate securely. Of course, the devil is in the details of how to make this secure, but one of the keys to OAuth and other identity protocols is removing the dependency on password proliferation.

Reliance on passwords is information security's crystal meth addiction: Everyone -- from security geeks to project managers to users -- knows they are wrong (not secure, painful), but we keep using them anyway.

OAuth 1.0 showed much promise here. The 1.0 specification calls for tokens to include digital signatures and hashes to protect credentials and requests. Unfortunately, from a security perspective, the 2.0 spec removes these and many other security protections

So it's a step backward from a security capability standpoint, but is the trade-off necessary to get more adoption and better integration? Is the security bar too low on OAuth 2.0? Reasonable (and unreasonable) people can disagree on these points, but it needs to be framed by the art of the possible. The world is lousy, with security protocols that have never been implemented or scaled; the only ones that matter are the ones that enable adoption and integration.

There are reasonably safe ways to deploy OAuth 2.0, though doing so requires that implementers know its limitations. For example, to deal with replay, MITM, and other attacks, the protocol must be protected by Transport Layer Security (TLS). OAuth 2.0 and TLS must always go together, like curry and chutney. Further, OAuth 2.0, like any identity protocol, makes no particular guarantee that the service provider code doesn't mishandle authorization. The service provider must implement attribute-based access control services to ensure the authorization services perform as expected.

Amid all of the technical churn, in September Google shipped its OAuth implementation based on the 2.0 specification. Is Google's OAuth release a step forward or a step back? From where I sit, Google has learned to crawl. It's a good opening, but not an end game. We need to walk and run next.

So while it's not the end game, it looks like progress on putting down the password crystal meth pipe, as one developer commented on Google's release: "After implementing my own authentication for my app, I really would have appreciated something like this!"

It's 2012. Authentication and authorization should not have to be Columbus in the New World. Each developer should not have to independently come up with his own implementation; these services are fundamental to every app. Frameworks should ship with identity protocols that make users more secure, developers' lives easier, and clear statements around safe ways to use and implement.

Gunnar Peterson is a Managing Principal at Arctec Group Gunnar Peterson (@oneraindrop) works on AppSec - Cloud, Mobile and Identity. He maintains a blog at http://1raindrop.typepad.com. View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading December Tech Digest
Experts weigh in on the pros and cons of end-user security training.
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-3407
Published: 2014-11-27
The SSL VPN implementation in Cisco Adaptive Security Appliance (ASA) Software 9.3(.2) and earlier does not properly allocate memory blocks during HTTP packet handling, which allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCuq68888.

CVE-2014-4829
Published: 2014-11-27
Cross-site request forgery (CSRF) vulnerability in IBM Security QRadar SIEM and QRadar Risk Manager 7.1 before MR2 Patch 9 and 7.2 before 7.2.4 Patch 1, and QRadar Vulnerability Manager 7.2 before 7.2.4 Patch 1, allows remote attackers to hijack the authentication of arbitrary users for requests tha...

CVE-2014-4831
Published: 2014-11-27
IBM Security QRadar SIEM and QRadar Risk Manager 7.1 before MR2 Patch 9 and 7.2 before 7.2.4 Patch 1, and QRadar Vulnerability Manager 7.2 before 7.2.4 Patch 1, allow remote attackers to hijack sessions via unspecified vectors.

CVE-2014-4832
Published: 2014-11-27
IBM Security QRadar SIEM and QRadar Risk Manager 7.1 before MR2 Patch 9 and 7.2 before 7.2.4 Patch 1, and QRadar Vulnerability Manager 7.2 before 7.2.4 Patch 1, allow remote attackers to obtain sensitive cookie information by sniffing the network during an HTTP session.

CVE-2014-4883
Published: 2014-11-27
resolv.c in the DNS resolver in uIP, and dns.c in the DNS resolver in lwIP 1.4.1 and earlier, does not use random values for ID fields and source ports of DNS query packets, which makes it easier for man-in-the-middle attackers to conduct cache-poisoning attacks via spoofed reply packets.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Now that the holiday season is about to begin both online and in stores, will this be yet another season of nonstop gifting to cybercriminals?