Perimeter
10/8/2012
11:46 AM
Gunnar Peterson
Gunnar Peterson
Commentary
Connect Directly
RSS
E-Mail
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
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0972
Published: 2014-08-01
The kgsl graphics driver for the Linux kernel 3.x, as used in Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, does not properly prevent write access to IOMMU context registers, which allows local users to select a custom page table, and consequently write ...

CVE-2014-2627
Published: 2014-08-01
Unspecified vulnerability in HP NonStop NetBatch G06.14 through G06.32.01, H06 through H06.28, and J06 through J06.17.01 allows remote authenticated users to gain privileges for NetBatch job execution via unknown vectors.

CVE-2014-3009
Published: 2014-08-01
The GDS component in IBM InfoSphere Master Data Management - Collaborative Edition 10.0 through 11.0 and InfoSphere Master Data Management Server for Product Information Management 9.0 and 9.1 does not properly handle FRAME elements, which makes it easier for remote authenticated users to conduct ph...

CVE-2014-3302
Published: 2014-08-01
user.php in Cisco WebEx Meetings Server 1.5(.1.131) and earlier does not properly implement the token timer for authenticated encryption, which allows remote attackers to obtain sensitive information via a crafted URL, aka Bug ID CSCuj81708.

CVE-2014-3534
Published: 2014-08-01
arch/s390/kernel/ptrace.c in the Linux kernel before 3.15.8 on the s390 platform does not properly restrict address-space control operations in PTRACE_POKEUSR_AREA requests, which allows local users to obtain read and write access to kernel memory locations, and consequently gain privileges, via a c...

Best of the Web
Dark Reading Radio