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

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
Mobile Banking Malware Up 50% in First Half of 2019
Kelly Sheridan, Staff Editor, Dark Reading,  1/17/2020
Exploits Released for As-Yet Unpatched Critical Citrix Flaw
Jai Vijayan, Contributing Writer,  1/13/2020
Microsoft to Officially End Support for Windows 7, Server 2008
Kelly Sheridan, Staff Editor, Dark Reading,  1/13/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
[Just Released] How Enterprises are Attacking the Cybersecurity Problem
[Just Released] How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-7227
PUBLISHED: 2020-01-18
Westermo MRD-315 1.7.3 and 1.7.4 devices have an information disclosure vulnerability that allows an authenticated remote attacker to retrieve the source code of different functions of the web application via requests that lack certain mandatory parameters. This affects ifaces-diag.asp, system.asp, ...
CVE-2019-15625
PUBLISHED: 2020-01-18
A memory usage vulnerability exists in Trend Micro Password Manager 3.8 that could allow an attacker with access and permissions to the victim's memory processes to extract sensitive information.
CVE-2019-19696
PUBLISHED: 2020-01-18
A RootCA vulnerability found in Trend Micro Password Manager for Windows and macOS exists where the localhost.key of RootCA.crt might be improperly accessed by an unauthorized party and could be used to create malicious self-signed SSL certificates, allowing an attacker to misdirect a user to phishi...
CVE-2019-19697
PUBLISHED: 2020-01-18
An arbitrary code execution vulnerability exists in the Trend Micro Security 2019 (v15) consumer family of products which could allow an attacker to gain elevated privileges and tamper with protected services by disabling or otherwise preventing them to start. An attacker must already have administr...
CVE-2019-20357
PUBLISHED: 2020-01-18
A Persistent Arbitrary Code Execution vulnerability exists in the Trend Micro Security 2020 (v160 and 2019 (v15) consumer familiy of products which could potentially allow an attacker the ability to create a malicious program to escalate privileges and attain persistence on a vulnerable system.