This week, Twitter’s OAauth keys leaked to Github. So what does that mean? Don’t panic. The consequences of a client application’s key being compromised are not 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 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 that you do not trust. If you seem to be redirected to Twitter after clicking a link or through any other means unexpectedly, don’t consent to an application accessing Twitter on your behalf even if this appears to be pointing to an application you trust.
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 aren’t really secrets. Twitter may create new keys for their application and look for better ways to obfuscate them but it’s only a matter of time before these new secrets are also compromised.
This is the second time in three weeks that vulnerabilities are found on prominent social providers. February 19, Egor Homakov described how the Facebook OAuth authorization server could be tricked in facilitating a fishing attack. In both the Twitter and Facebook cases, the vulnerabilities were related to OAuth. It would be easy to point the finger at OAuth but the fact is that these vulnerabilities are the result of an incorrect use of OAuth: Facebook fails to validate redirection Uniform Resource Identifiers (URIs), while Twitter embeds shared secrets in public clients.
Although the validation of redirection URIs is a pretty basic precaution that any OAuth authorization server should implement, the correct way to use OAuth with native applications on a mobile platform is a much more complicated matter. As I discussed 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 third-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.
Photo Credit: The To/Shutterstock
Francois Lascelles is Layer 7’s Chief Architect. He guides the company's solutions architecture team and aligns product evolution with field trends. Lascelles helps enterprise architects apply the latest standards and patterns. He holds a Bachelor of Engineering degree from Ecole Polytechnique de Montreal. You can follow him on Twitter: @flascelles