If there’s one thing that a single sign-on service is practically useless without, it’s the cryptographic algorithm it uses to store user credentials safely in its servers. But what if it has an algorithm, and instead of working as it should, simply blows out all of its data in a frenzy? That’s just as bad, isn’t it? Something similar just happened not too many days ago when OneLogin was compromised in such a way that the hackers were able to decrypt any passwords and usernames they wanted to at their whim.
At the beginning of this month, OneLogin’s chief information security officer revealed that unauthorized access has been detected on their servers. The words “unauthorized access” do little to embody the gravity of what happened; it was more like a significant breach of their encryption capabilities to such an extent that user credentials were visible in plaintext.
Here’s what makes this OneLogin hack so significant.
It’s one thing to hack an encrypted database. The passwords stored within it are still illegible. Users of the service may become a little spooked, but that’s as far as the damage goes. Ultimately, the hackers will hit a brick wall as their breach of the database gives them nothing but indecipherable versions of the data they’re looking for.
It’s an entirely different matter, however, when the cryptographic algorithm of a database is compromised because the hackers stole the keys that will turn the indecipherable gobbledygook into a massive array of human-readable text showing every single password and username stored within its tables. Not only does this spook users, but it also gives them a good reason for it!
The company has worked diligently to inform affected customers of the breach and advise them on the steps they should take to prevent any further damage. A total of 2,000 companies spanning 44 countries were affected in this attack.
Investigations into the incident reveal that the hackers gained access to a list of keys stored within OneLogin’s servers and used them to access a smaller intermediate host that stored credentials of a number of the service’s users.
Let’s take a walk through History Lane, shall we?
This is not the first time that the company experienced a breach. A little under a year ago, in August of 2016, another incident occurred in which hackers stole plaintext secure notes from OneLogin’s database.
This isn’t the only company that was affected by breaches, either. LastPass not only had the misfortune of having a bug in its Chrome extension that would allow hackers to just grab passwords at a whim (only a year after other message hijacking bugs were discovered) , but it also suffered a minor breach in which master password hashes were stolen from its database.
This isn’t going to stop, unless…
The complacency of an “it’s going to be different this time” mentality might be a bit tempting, but it is imperative that we recognize the underlying cause of all of these incidents. Unless we do this, we’ll never reach a point where the breaches will stop.
As strong as it is, any form of encryption is entirely useless once hackers have reached the keys that suddenly provide them with the tools they need to completely decipher user credentials. It defeats the entire purpose of being an identity manager. You’re not going to gain points by hiding the keys deeper inside of the very channels the hackers used to get them in the first place!
Rather than burying our heads deeper in the sand, it’s perhaps time we start using them to come up with new ways of combatting this issue. If you want to keep a door locked, perhaps it’s not a good idea to leave the key within the reach of would-be thieves.
Rather than storing keys on-site, we’ve taken another approach: Our service gives its users the ability to generate their own keys and keep them in their own hands.
This accomplishes two things:
- It stops the database from being the single point of failure for everything. Since each user is in itself a separate point of failure, a potential breach would not affect the entire service.
- It hands complete control of the users’ identities to the users, where they belong. This allows them more freedom and flexibility in managing their own security policies.
It sounds like a simple monkey wrench solution, but it’s the crucial ingredient that makes the difference between repeated embarrassing breaches and virtual immunity against them. Rather than pouring valuable resources into a solution that offers no guarantees, we have decided to capitalize on a proper method to not only combat but also prevent the threat of breaches on the community of users and companies that place their trust in us with their identities. It really is time we start getting as close as we can to a perfect cloud (pun intended) solution to this problem!