Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

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

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/9/2020
Omdia Research Launches Page on Dark Reading
Tim Wilson, Editor in Chief, Dark Reading 7/9/2020
4 Security Tips as the July 15 Tax-Day Extension Draws Near
Shane Buckley, President & Chief Operating Officer, Gigamon,  7/10/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15105
PUBLISHED: 2020-07-10
Django Two-Factor Authentication before 1.12, stores the user's password in clear text in the user session (base64-encoded). The password is stored in the session when the user submits their username and password, and is removed once they complete authentication by entering a two-factor authenticati...
CVE-2020-11061
PUBLISHED: 2020-07-10
In Bareos Director less than or equal to 16.2.10, 17.2.9, 18.2.8, and 19.2.7, a heap overflow allows a malicious client to corrupt the director's memory via oversized digest strings sent during initialization of a verify job. Disabling verify jobs mitigates the problem. This issue is also patched in...
CVE-2020-4042
PUBLISHED: 2020-07-10
Bareos before version 19.2.8 and earlier allows a malicious client to communicate with the director without knowledge of the shared secret if the director allows client initiated connection and connects to the client itself. The malicious client can replay the Bareos director's cram-md5 challenge to...
CVE-2020-11081
PUBLISHED: 2020-07-10
osquery before version 4.4.0 enables a priviledge escalation vulnerability. If a Window system is configured with a PATH that contains a user-writable directory then a local user may write a zlib1.dll DLL, which osquery will attempt to load. Since osquery runs with elevated privileges this enables l...
CVE-2020-6114
PUBLISHED: 2020-07-10
An exploitable SQL injection vulnerability exists in the Admin Reports functionality of Glacies IceHRM v26.6.0.OS (Commit bb274de1751ffb9d09482fd2538f9950a94c510a) . A specially crafted HTTP request can cause SQL injection. An attacker can make an authenticated HTTP request to trigger this vulnerabi...