OAuth – the privacy time bomb

Andy Baio writes in Wired about the privacy dangers of OAuth.

While OAuth enables OAuth Providers to replace passwords with tokens to improve the security of authentication and authorization to third party applications, in many cases it gives those applications access to much more of your personal information than is needed for them to perform their functions. This only increases the risk associated with breaches of personal data at these third party application providers.

Andy focuses on Gmail because the risk of using them as an OAuth Provider is greater. As Andy says:

For Twitter, the consequences are unlikely to be serious since almost all activity is public. For Facebook, a mass leak of private Facebook photos could certainly be embarrassing. But for Gmail, I’m very concerned that it opens a major security flaw that’s begging to be exploited.

“You may trust Google to keep your email safe, but do you trust a three-month-old Y Combinator-funded startup created by three college kids? Or a side project from an engineer working in his 20 percent time? How about a disgruntled or curious employee of one of these third-party services?”

If you are using your GMail (Google) credentials to just authenticate to a third party application, why should the third party application have access to your emails? In the case of Xobni or Unsubscribe, for example, you do need to give them access rights because they are providing specific functions that need access to Gmail content. But why does Unsubscribe need access to message content when all it really needs is access to email senders? When you decided to use Unsubscribe, why can’t you limit them to only your Senders? The bottom line is that by using OAuth you are trusting the third party applications not to abuse the privileges you are giving them and that they have implemented effective security controls.

While Andy provides some good advice to people who use their Google, Twitter, or Facebook credentials for other applications, there is no technical reason for the third party applications to get access to so much personal information. In other words, when you allow a third party application to use one of your primary applications (OAuth Providers) for authentication and/or authorization, you should be able to control the functions and data to which the third party has access. In order for this to happen, the Googles, Facebooks, and Twitters must build in more fine-grained access controls.

At present, the OAuth providers do not seem to be motivated to limit access to user content by third party applications based on the needs of those applications. One reason might be that most users simply don’t realize how much access they are giving to third party applications when they use an OAuth Provider. With no user pressure requesting finer grained access, why would the OAuth Providers bother?

Aside from lack of user pressure, it seems to me that the OAuth Providers are economically motivated to maintain the status quo for two reasons. First, they are competing with each other to become the cornerstone for their users’ online lives and want keep the OAuth user interface as simple as possible. In other words, if authorization is too fine grained, users will have too many choices and will decide not to use that OAuth Provider. Second, the OAuth Providers want to keep things as simple as possible for third party developers to attract them.

I would hate to see the Federal Government get involved to force the OAuth Providers to provide more fine-grained access control. But I am afraid that a few highly publicized breaches will have that affect.

As Enterprises are moving to a Zero Trust Model, so must consumers.

 

 


 

 

 

 

 

 

Twitter’s flawed OAuth implementation

I meant to post this last week. Ryan Paul at ars technica wrote an important article detailing the flaws in Twitter’s implementation of OAuth. This is serious because it is the only method for “users to grant a third-party application access to their account without having to provide that application with their credentials.” He also details the flaws of OAuth 1.0a, but holds out hope for OAuth 2.0, which the IETF is currently working on. Let’s hope they get it right this time.

Twitter officially disabled Basic authentication this week, the final step in the company’s transition to mandatory OAuth authentication. Sadly, Twitter’s extremely poor implementation of the OAuth standard offers a textbook example of how to do it wrong. This article will explore some of the problems with Twitter’s OAuth implementation and some potential pitfalls inherent to the standard. I will also show you how I managed to compromise the secret OAuth key in Twitter’s very own official client application for Android.

The article goes on to trash OAuth 1.0a as well:

…OAuth 1.0a is a horrible solution to a very difficult problem. It works acceptably well for server-to-server authentication, but there are far too many unresolved issues in the current specification for it to be used as-is on a widespread basis for desktop applications. It’s simply not mature enough yet.

There is hope though:

I think that OAuth 2.0—the next version of the standard—will address many of the problems and will make it safer and more suitable for adoption. The current IETF version of the 2.0 draft still requires a lot of work, however. It still doesn’t really provide guidance on how to handle consumer secret keys for desktop applications, for example. In light of the heavy involvement in the draft process by Facebook’s David Recordon, I’m really hopeful that the official standard will adopt Facebook’s sane and reasonable approach to that problem.

Finally:

Although I think that OAuth is salvageable and may eventually live up to the hype, my opinion of Twitter is less positive. The service seriously botched its OAuth implementation and demonstrated, yet again, that it lacks the engineering competence that is needed to reliably operate its service. Twitter should review the OAuth standard and take a close look at how Google and Facebook are using OAuth for guidance about the proper approach.