In the aftermath of the LinkedIn password hack, everyone’s wagging their fingers at the usual suspects. It’s the end users’ fault for choosing weak passwords. It’s LinkedIn’s fault for not salting their password hashes.
Eh. Maybe.
Yes, choosing stronger passwords increases the time it takes a hacker to attack them with brute force attacks. But I’d argue that maybe end users are reacting appropriately to the level of risk and liability they are facing at LinkedIn.
And yes, salting the hashes can help. Some. Changing hash algorithms can delay a hacker significantly.
Root Cause of the LinkedIn Password Hack
If the bad guys have the file of hashes they can still persistently attack it off line on their own machines. Especially if you don’t know they have it. So all those discussions about hash algorithms and password salting are just delaying actions and wouldn’t have prevented the LinkedIn password hack.
Not arguing against encouraging users to choose better passwords. Not arguing against companies choosing stronger hash algorithms. But those issues are only relevant after the password hashes have been stolen.
What I want to know is, “How did the hackers obtain 6.46 million hashed passwords from LinkedIn in the first place?” Isn’t that the where the root vulnerability is for the LinkedIn password hack? Isn’t that what needs to be fixed? I’m not aware of LinkedIn making any statements about how the hackers obtained the 6.46 million password hashes. LinkedIn might not even know. Might not ever know. In any case, the fundamental issue in the LinkedIn password hack is that the company, which I think of being a pretty reasonable, good intentioned “corporate citizen,” was unable to protect the password hashes. Isn’t that the real tragedy in this story?
Identity Providers as a Risk Transfer Tool
Put yourself in the position of LinkedIn right now. How would you deal with the LinkedIn password hack situation? All of a sudden you’re company has been forced into a very public spotlight and everyone is watching what you do, how you fix the problem. As a company you can spend a lot of time and money on forensics to figure out how the hacker obtained the 6.46 million password hashes. You might or might not be able to fix it. Can you be sure the LinkedIn password hack won’t happen again?
If I were LinkedIn, I’d at least be considering some alternate strategies. Could LinkedIn get those millions of LinkedIn password hashes out of LinkedIn’s domain, off its infrastructure, out of its hair? In other words, why not outsource its end user authentication, and all of those millions of passwords to an identity provider? Let someone else protect all those password hashes.
Heck, in a lot of cases, a company can outsource the authentication duties to another company at zero or low cost. Companies are doing this every day. They are going live with authentication strategies that require end users to use credentials from another service to authenticate and create their accounts. FaceBook, Twitter, and Google are the biggest identity providers that companies are relying on to authenticate their end users. But a company could set up trust relationships with as many of alternative identity providers as they need to cover their target market of end users.
The identity providers can then invest in the necessary infrastructure to keep those millions of passwords safe. They can invest in multifactor authentication. They can focus on staying one step ahead of the bad guys.
We usually think of federated identity management in terms of convenience for the end user and in terms of reducing costs for the service provider.
I wonder if federated identity management is also a reasonable risk transfer strategy for companies like LinkedIn that have to manage millions of end user passwords.
What do you think? Is outsourcing your end user identity management and authentication to an identity provider like FaceBook, Twitter, or Google an effective way to transfer this risk?
