The Proliferation of Under-protected OAuth Tokens

There is an exploding number of companies who exist to help companies manage users or data across cloud services. A company that uses SalesForce, Google G-Suite, Github, and dozens of other such services has a real challenge when it comes to provisioning users, helping them sign in across services, revoking their access, tracking what they’re paying for unnecessarily, collecting data into dashboards, and so forth.

In Mary Meeker’s just released 2017 Internet Trends report, it shows that Enterprises use on average around 1,000 cloud services — 91 for marketing purposes alone.

Cloud Apps in the Enterprise via Mary Meeker’s Internet Trends report.

Companies like ComputeNext, VendorHawk, OneLogin, Logrr, Kilpfolio, Okta, and many more are solving different aspects of the cloud service proliferation problem. For them to achieve their goals, they must act on behalf of users or administrators. In practice, that means they get OAuth tokens or API tokens, which are like virtual usernames and passwords for a service to use. These tokens typically give full read and write permissions for an account.

Which begs the question: how are those OAuth tokens being stored? How are they being protected? What happens if someone gets access to a system that stores these credentials?

OneLogin inadvertently provided an answer to this question when they announced the recent breach of their service, their second in 10 months. This breach gave an attacker access to the unencrypted credentials of OneLogin customers like Conde Nast, Dun and Bradstreet, and ARM.

Which begs the question: how are those OAuth tokens being stored?

In their blog post announcing the breach, OneLogin said, “While we encrypt certain sensitive data at rest, at this time we cannot rule out the possibility that the threat actor also obtained the ability to decrypt data.” Later they sent an email to customers saying, “All customers served by our US data center are affected; customer data was compromised, including the ability to decrypt encrypted data.”

Usually, when people say that data is encrypted “at rest,” it’s a euphemism for the data being transparently encrypted as with disk encryption or transparent database encryption.

This type of encryption protects against physical theft, but not digital theft. When a laptop is stolen or someone takes a hard drive out of a server, that transparent encryption is crucial. But if an attacker gains access to a running server, the encryption is transparent to them, too.

If we credit OneLogin with going further than basic transparent encryption, then their statement still indicates that they also have keys on the server (or else the attacker would not have accessed unencrypted data). This is akin to locking a desk drawer and then leaving the key on top of the desk.

As a result of this breach, customers need to change their passwords (admin as well as all users), generate new API keys for their services, and create new OAuth tokens — if they dare to share those again.

This is akin to locking a desk drawer and then leaving the key on top of the desk.

OneLogin is not alone. Of the integration services we researched, and we looked at dozens, not one claims to protect those tokens using end-to-end encryption or zero-trust mechanisms.

Customers should demand stronger protection of their most sensitive data, and they should demand that they retain control of that data, including the keys used to decrypt it. IronCore can help cloud vendors secure sensitive data like OAuth tokens and offer their customers zero-trust services that use end-to-end encryption to provide control of customer data without the loss of functionality.

It’s time for the cloud to grow up and use a more robust security model including strong encryption so that breaches like these are a non-event with no loss of unencrypted sensitive data.