The skinny on the LinkedIn breach
It was revealed last Wednesday that approximately 6.5 million LinkedIn user passwords were posted on a site that is purportedly run by hacker groups. Much has already been said on this topic, but I’ll briefly recap the highlights of the breach for those who may have missed this story. The good news: the passwords posted on the site were not in the clear – they were hashed via the SHA-1 hashing algorithm. Not stored in the clear – score one for the good guys! Not so fast my friends. The bad news: they were apparently unsalted prior to hashing. Now, for the food inclined out there, you may be thinking “no big deal, you can salt them to taste after they are hashed.” But in this case, you need the salt (think of it as a dash of randomness that makes it extremely difficult to unscramble the original values) prior to applying the hashing algorithm.
With no salt applied, hackers have been able to decode half (or more) of the hashed passwords to reveal the plain-text value. Score one for the bad guys. On the bright side, it does not appear that the hackers obtained any other personally identifiable information (name, user name, etc.) to go along with the passwords, so potential for damage in this situation is minimal –given what we know today. How and why they only managed to snatch the passwords is somewhat
Leave it to the experts
Let me be clear: there is no product, method, or combination thereof that will protect you 100% of the time from data breaches such as this. However, there are well-understood techniques and procedures that can significantly reduce such events. The question is: will you take the time and trouble to do them? Tragically, the answer to this question is quite often "No".
One of the luminaries in the world of identity and access whom I greatly respect posted a quick summary and assessment of the LinkedIn breach. I completely agree with Craig’s assertion that service providers like LinkedIn should harden their environments up front. A major reason why UnboundID exists is to make this easier for service providers. Craig goes on to assert that this breach represents yet another reason for the adoption of what Kuppinger-Cole, Kim Cameron (Microsoft), and others are calling IDMaaS (Identity Management as a Service). For simplicity, let’s call this outsourcing or externalizing identity management functions from applications to another provider in the cloud. He goes on to say:
“It is just too expensive and hard for every company to have the required expertise to design hardened systems in today’s IT environment.”
I believe “outsourcing” the functions of identity is ultimately the correct answer for most companies, especially the traditional enterprise type. But it’s not a palatable option for companies – like LinkedIn – whose business models are built upon customer (personal) data. For these companies, relinquishing control of their most valuable asset is not really an option. For instance, one of the first problems is drawing the line on what is and is not considered “identity” data. Usernames and passwords are pretty straight forward, but what about other personally identifiable data that might be necessary for making authorization decisions? What about basic profile data? In the case of LinkedIn, are the relationships between professionals considered identity data? Further, in LinkedIn’s case, they are currently operating as an Identity Provider, and therefore provide passwords on behalf of their customers for use on other sites. Even if you are able to carve out a portion of identity data that could be outsourced to someone else, when you are working with 100 million+ customer populations, maintaining your SLAs and a consistent customer experience with the stuff you control is hard enough without introducing a potential point of failure that is outside of your control.
Another approach that is true to the spirit of Craig’s assertion (“identity and security is hard, so leave it to the experts”), that doesn’t require relinquishing control of the data is to leverage solutions that were purpose-built for handling the data in your core infrastructure – like UnboundID.
At UnboundID, we like ours salted
Customer data breaches are always of interest to me because of UnboundID’s focus on protecting this data, but this one is of particular interest for a couple reasons:
1) This is password data, which should always be secured with the strongest of controls, and
2) Our core data store product shares the same underlying key/value database engine (Berkeley DB Java Edition) as Project Voldemort, which was designed and built to support operations at LinkedIn.
I can’t be certain that Voldemort was the data store that was compromised at LinkedIn, but let’s assume it was, for sake of comparison. Voldemort is an interesting comparison to our technology, given that both are highly distributed key/value data stores (NoSQL Solutions) built on the same core engine. You can read this post from last year that provides a few more details on our architecture. One of the biggest differences between UnboundID’s technology, and that of other big data solutions on the market (like Voldemort), is our focus on data security. Our products are purpose-built for managing, protecting, and serving customer data in real-time. For instance, the out-of-the-box default for passwords is salted SHA-1, and we support as high as salted SHA-512 with a simple configuration change. You can read more about our focus on security here, here, and here. We take data security seriously - it’s what we do.
Chasing the sirens
Let’s talk frankly for a moment. I would be thrilled if LinkedIn contacted us to help them better protect and share their customer data as a result of reading this post. But like so many other technology-minded companies who have yet to learn that their core competency is not building newfangled databases, they are more likely to go it alone and build it themselves.
No, we don’t expect our “ambulance chasing” to bear fruit with LinkedIn. But maybe there’s someone else out there who is contemplating building the next LinkedIn, or mulling over options they have for securing their customer identity data, and maybe they are open to alternatives. If that’s you, then drop us a line – we’d love to assist you.
For more on this story, click here.