Well, it has happened again. Unsecured API keys have lead to a major data breach affecting a broad swath of the web. This is not a fun post to write, and we do so not to pour salt in the wounds of anyone in the community. We do it to bring light to a often overlooked aspect of API security that more and more is becoming a common attack vector, and with the massive rise of the API economy, it is a problem that is not going to go away.
On May 31st, OneLogin, a leading service provider for authentication and password management was compromised by nefarious actor(s) causing the exposure to a massive quantity of user information. OneLogin provides services for single-sign-on (SSO) and identity and access management (IAM) to over 2,000 enterprises in 44 countries. From healthcare, financial services, legal services and large commerce, millions of customers have adopted OneLogin’s products for management of credentials and web platforms. OneLogin is a leader in the field of identity management and security so they are no slouches when it comes to funding, technical expertise, and knowledge.
Let this be a warning -- if it can happen to OneLogin, it can happen to you!
So, what happened? According to the Company the entire US operating region was compromised when a, “threat actor obtained access to a set of AWS keys and used them to access the AWS API from an intermediate host with another, smaller service provider in the US.”. With that access, the perpetrator was then able to create multiple instances which were then used for reconnaissance and accessing databases. While the Onelogin data was encrypted at rest, it appears that the keys for the encrypted data were also stored within the same infrastructure and possibly used to decrypt data.
OneLogin has contacted their customers and many are reportedly needing to rebuild their entire authentication systems, rolling keys, passwords, and tokens for their entire enterprise. The full impact and damage of this breach will only be fully accounted for in the months ahead, but the immediate costs (development, brand, security fees, data protection, etc.) are already significant.
What can we learn from this?
Protect your keys! Most developers do not give API keys the respect they deserve. Great damage can be done with API keys and you should always use proper storage and chain of custody protocols for managing your keys; which includes using Lockr as a secure storage outside your infrastructure.
If it can happen to OneLogin, it can happen to you. Don’t assume you are not a target or your business isn’t susceptible because you are a small business. Likewise, as an enterprise you are still vulnerable due to the large number of APIs you consume. This can happen to anyone.
Be proactive. Don’t wait until you have had a major security event to invest in the proper tools and protocols to protecting your data and credentials.
Why Lockr Exists?
Ultimately, this is the main reason behind why we created Lockr, to prevent this type of event. Lockr keeps your keys under multiple layers of encryption in a location outside your infrastructure, no matter what cloud it is in.
We’d be amiss if we didn’t talk about how this applies to us at Lockr. We created Lockr with the idea that API keys and access tokens are a vital aspect of application security, one that hasn’t been addressed in a simple and universal fashion. With Lockr, we provide a simple way to store API keys and access tokens in a separate environment from the application which needs it. Additionally, Lockr encrypts the token prior to ever leaving the application environment to ensure no one, not Lockr or even a nefarious actor(s) can decrypt and use it.
Additionally, the separation of API key from ability to access encryption keys is critical. By storing not only API keys but encryption keys in Lockr, no longer would encrypted data be compromised when an API key is.