As the month of August was coming to a close, users of an identity management (IDM) and single sign-on provider were shocked to find that many of their encrypted notes since at least the 2nd of June have been snooped on by hackers. The incident prompts people to ask themselves several questions, the most important of which is whether they could trust a single entity with so much of their sensitive data (which, in this case, includes passwords for their most important accounts). Events like these hurt the trust of not just the company whose security was compromised, but also that of providers of similar services. Since recent events are indicating that Single sign-on providers and password managers are becoming honeypots for hackers, we thought it would be wise to iron out the details on this particular incident, discuss the implications, make suggestions on what could be done to improve security for identity management (IM) and single sign-on providers, and demonstrate how our system places natural barriers against these attacks without requiring a massive capital investment.
For those who want a quick summary, the target company’s account of this incident is that the breach exploited a bug in which their secure notes (encrypted notes that you can store for later use) were visible in their logging system in plain text before the encryption took place. Of course, in order to view the logs, one has to be logged into an account that can access it. The intruder compromised the password of an employee to accomplish this. We do not know whether the employee was manipulated into handing over their password or did it willingly in an act of sabotage. Either way, an employee’s account was used for something malicious. Intentions aren’t necessarily relevant when analyzing what happened in this particular case.
How Encryption Can Fail Us
We mentioned above that an employee’s account was exploited because that is one of the ways in which encryption can be rendered useless when it is managed improperly. This incident involved a bug. In theory, had the bug not existed, it would have been “game over” for the hacker. The attack would only have gone so far and would never reach its fruition. The moment of crowning glory for the hacker came as a result of a series of human errors that played in their favor. Of course, a more enterprising hacker would have simply looked for other ways in, up to and including manipulating gullible employees.
But here’s the scary part: This can happen to a vast majority of encrypted services we trust our data with on a daily basis. The lesson here is that having data encrypted isn’t the save-all it’s been hyped up to be by various tech websites and reporters. Don’t get us wrong: It’s not the encryption’s fault but rather the fault of human beings who are prone to overlook points of vulnerability. Although cryptography is a tool that is used for
obfuscating data in such a way that it is unreadable without a key, there are situations such this one that betray its purpose.
How We Solve This Problem
Because we are people (and people suck at anticipating every possible doomsday scenario), we not only have to battle with hackers, but also with ourselves. We have a tendency to overlook situations that hackers could take advantage of, which is especially true as the feature sets of pieces of software and their code grow in complexity. As you create more software, you’ll have to anticipate an exponentially higher amount of scenarios. That is, unless you do something to simplify the process of securing data.
To do this, we have a solution we’ve applied: We let you have control over the encryption. This simple shift in control makes it impossible for us or anyone hired by us to ever see your data in plain text. Because of this, we are forced to develop around your data rather than use it in any step of the storage and management process. It creates a closed compartmentalized loop that you have access to in the most exclusive manner possible. And we do this by simply allowing you to have your own encryption key, which is never stored in our systems. Sure, that means that (theoretically) you have “one more password to remember”. But this extra step is what sets us apart from quite literally every other service on the internet in one crucial manner: We guarantee the safety and intimacy of your data by excluding everyone (including our own software) from the privilege of accessing it.
Think about it: We run a data encryption, single sign-on and identity management service. This means that you’re trusting the passwords to your accounts and your most sensitive data—the most intimate stuff you own on the web—to a piece of software. Relegating control to the company behind that software means that you’re forced to trust every single human being who developed it and every hand the data goes through in its entire lifecycle.
However small the risk would be, the cost of placing that much trust in something objectively outweighs the benefit in almost every scenario unless, of course, you didn’t have to trust it. This is what having your own key does. You relinquish no control and therefore are never forced to trust anyone or anything. This is the one way in which we can ensure that you have complete data ownership even when it is not stored in a medium that you own. It’s like having a locker where you can store your most precious belongings. Would you rather hand the key over to the entity owning the locker, or put it in your pocket? Which of these two tells you more clearly that the items you left inside are still completely yours?