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-2013-6306
Published: 2014-08-22
Unspecified vulnerability on IBM Power 7 Systems 740 before 740.70 01Ax740_121, 760 before 760.40 Ax760_078, and 770 before 770.30 01Ax770_062 allows local users to gain Service Processor privileges via unknown vectors.

CVE-2014-0232
Published: 2014-08-22
Multiple cross-site scripting (XSS) vulnerabilities in framework/common/webcommon/includes/messages.ftl in Apache OFBiz 11.04.01 before 11.04.05 and 12.04.01 before 12.04.04 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors, which are not properly handled in a (1)...

CVE-2014-3525
Published: 2014-08-22
Unspecified vulnerability in Apache Traffic Server 4.2.1.1 and 5.x before 5.0.1 has unknown impact and attack vectors, possibly related to health checks.

CVE-2014-3563
Published: 2014-08-22
Multiple unspecified vulnerabilities in Salt (aka SaltStack) before 2014.1.10 allow local users to have an unspecified impact via vectors related to temporary file creation in (1) seed.py, (2) salt-ssh, or (3) salt-cloud.

CVE-2014-3587
Published: 2014-08-22
Integer overflow in the cdf_read_property_info function in cdf.c in file through 5.19, as used in the Fileinfo component in PHP before 5.4.32 and 5.5.x before 5.5.16, allows remote attackers to cause a denial of service (application crash) via a crafted CDF file. NOTE: this vulnerability exists bec...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Three interviews on critical embedded systems and security, recorded at Black Hat 2014 in Las Vegas.