OAuth Protects Users in Compromise of Social Site Buffer

Last week, the social posting site Buffer had both their database of access tokens and their OAuth client secrets compromised by attacks on Github and MongoHQ. Buffer uses Github to store their client_secret in Source Code and MongoHQ to store their access tokens.

The attackers were quite sophisticated, though Buffer could and should have taken some simple precautions that would have at least made it significantly harder for the attackers.

Previously, I contributed to a detailed article on ProgramableWeb that looks at what happened.

I want to reiterate that given the security lapses it is good Buffer was using OAuth and not storing passwords for Facebook and Twitter. The tokens were revoked in the Twitter case and the client secret changed (and used) in the Facebook case to remedy the situation with much less user impact than there might have been.

One thing that we need to do a better job of is helping OAuth clients with advice on securing tokens and the associated secrets in cloud and other sorts of environments.

At the OAuth WG meeting at the IETF yesterday we did get agreement on moving ahead with the Proof of Possession work to prevent stolen tokens from being used by attackers.

However there are basic security things that are available now that Buffer and other developers are electing to ignore because security is just anoying until you discover that you have been hacked and your customers have lost confidence in you.

At the Federation Interoperability Work Group at Kantara we have been asked to provide deployment profiles for OAuth 2 and OpenID Connect for several governments. I am hoping that some of that guidance will be more generally applicable.

This guest post comes from John Bradley. John is Senior technical architect in the CTO Office at Ping Identity. He is on the board of the openID Foundation, and one of the core authors of OpenID Connect, as well as being part of the IETF OAuth and JOSE workgroups where he is author of several of the specifications. John is also co-chair of the Federation interoperability Working Group at Kantara that oversees deployment and conformance profiles for SAML and other protocols. He has a background in Telecom and has worked for a number of Governments on Identity management issues. Follow him @ve7jtb.

For other coverage of these events, check out these great posts:

Be sure to read the next Best Practices article: 4 Reasons To Ditch Apache Struts and Embrace JavaScript