Enterprise Integration Zone is brought to you in partnership with:

As the Technical Director, Europe for Layer 7 Technologies, Francois Lascelles advises global corporations and governments in designing and implementing secure SOA and cloud based solutions. Francois joined Layer 7 in its first days back in 2002 and has been contributing ever since to the evolution of the SecureSpan SOA infrastructure product line. Francois is co-author of Prentice Hall’s upcoming SOA Security book. Layer 7 Technologies is an Enterprise SOA and Cloud infrastructure provider. Follow me on twitter http://twitter.com/flascelles Francois is a DZone MVB and is not an employee of DZone and has posted 28 posts at DZone. You can read more from them at their website. View Full User Profile

Compromised Twitter OAuth Keys

03.10.2013
| 3430 views |
  • submit to reddit
So twitter’s oauth keys have leaked. What does that mean? Don’t panic. The consequences of a client application’s key being compromised is as serious as user credentials being compromised. The risk associated with this breach is that a malicious application tricking you in participating in an OAuth handshake (fishing) could access the twitter API on your behalf. Attackers might come up with clever ways to exploit this leak. In the meantime, avoid using twitter through any application other than the twitter application itself.

OAuth distinguishes between confidential and public clients. Applications that you can publicly download on your own device (mobile or not) fall in the public category because they are subject to their embedded secret being reverse engineered as probably happened in this case. This incident is a good illustration of the fact that client secrets should not form the basis of a secure session in public clients like mobile applications because, well, those secrets are easily discovered. Twitter may create new keys for their application and look for ways to better obfuscate them but it’s only a matter of time before these new secrets are also compromised.

As I was discussing at Cloud Security Alliance and in our last tech talk, authentication involving redirection between applications on mobile device has its risks. There are ways to completely secure this between applications of a same domain but solving this across 3rd party mobile apps, in a fool-proof way requires either something like a multi-factor authentication or the provisioning of client secrets post-application download which is often not practical.

Either way, API and application providers would do well not relying on pseudo-secrets embedded in publicly available applications as the basis of any security. In the case of client applications issued by the same provider as the API they consume (e.g. the official twitter app), the password grant type make a lot more sense to me and provides a better UX.

Published at DZone with permission of Francois Lascelles, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)