OneLogin, an online service that lets users manage logins to sites and apps from a single platform, says it has suffered a security breach in which customer data was compromised, including the ability to decrypt encrypted data.
Headquartered in San Francisco, OneLogin provides single sign-on and identity management for cloud-base applications. OneLogin counts among its customers some 2,000 companies in 44 countries, over 300 app vendors and more than 70 software-as-a-service providers.
A breach that allowed intruders to decrypt customer data could be extremely damaging for affected customers. After OneLogin customers sign into their account, the service takes care of remembering and supplying the customer’s usernames and passwords for all of their other applications.
In a brief blog post Wednesday, OneLogin chief information security officer Alvaro Hoyos wrote that the company detected unauthorized access to OneLogin data.
“Today we detected unauthorized access to OneLogin data in our US data region. We have since blocked this unauthorized access, reported the matter to law enforcement, and are working with an independent security firm to determine how the unauthorized access happened and verify the extent of the impact of this incident. We want our customers to know that the trust they have placed in us is paramount.”
“While our investigation is still ongoing, we have already reached out to impacted customers with specific recommended remediation steps and are actively working to determine how best to prevent such an incident from occurring in the future and will update our customers as these improvements are implemented.”
OneLogin’s blog post includes no other details, aside from a reference to the company’s compliance page. The company has not yet responded to request for comment. However, Motherboard has obtained a copy of a message OneLogin reportedly sent to its customers about the incident, and that missive contains a critical piece of information:
“Customer data was compromised, including the ability to decrypt encrypted data,” reads the message OneLogin sent to customers.
According to Motherboard, the message also directed customers to a list of required steps to minimize any damage from the breach, such as generating new API keys and OAuth tokens (OAuth being a system for logging into accounts), creating new security certificates as well as credentials; recycling any secrets stored in OneLogin’s Secure Notes feature; and having end-users update their passwords.
Gartner Inc. financial fraud analyst Avivah Litan said she has long discouraged companies from using cloud-based single sign-on services, arguing that they are the digital equivalent to an organization putting all of its eggs in one basket.
“It’s just such a massive single point of failure,” Litan said. “And this breach shows that other [cloud-based single sign-on] services are vulnerable, too. This is a big deal and it’s disruptive for victim customers, because they have to now change the inner guts of their authentication systems and there’s a lot of employee inconvenience while that’s going on.”
KrebsOnSecurity will likely update this story throughout the day as more details become available.
Update 7:54 p.m ET: OneLogin posted an update to its blog with more details about the breach:
“Our review has shown that 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. Evidence shows the attack started on May 31, 2017 around 2 am PST. Through the AWS API, the actor created several instances in our infrastructure to do reconnaissance. OneLogin staff was alerted of unusual database activity around 9 am PST and within minutes shut down the affected instance as well as the AWS keys that were used to create it.”
“The threat actor was able to access database tables that contain information about users, apps, and various types of keys. 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. We are thus erring on the side of caution and recommending actions our customers should take, which we have already communicated to our customers.”
According me it’s true that it has experienced a security violation in which consumer data was negotiated, with the capacity to decrypt encrypted data.
Data at rest protection is tricky.
How about this?
Your encryption keys are known to the system, but not to any human. The system won’t run until the keys are instantiated by ‘root’ but, when it is, the system informs nobody of the values of the keys. The keys aren’t stored anywhere on the system, so they can’t be stolen and, if they are changed, they re-encrypt the database, but still tell nobody the new values. Your database is encrypted with AES256, and hashed with SHA256 so, if it’s stolen, the hackers can have months of fun trying to brute-force the contents.
That’s how I’d do it, anyway.
Storing the decryption key is a very bad idea.
Passman uses both server side and client side encryption.
The client side encryption key is never send to the server.
Therefore it’s almost impossible to crack if an attacker gains access to the database
Companies need to build more robust vendor risk management programs to anticipate their greatest areas of vulnerability.