The fact that LinkedIn was breached has been well covered and confirmed, but in their confirmation they said something that I personally found insulting, more than anything else:
It is worth noting that the affected members who update their passwords and members whose passwords have not been compromised benefit from the enhanced security we just recently put in place, which includes hashing and salting of our current password databases.
So, they just recently started salting their hashes? Seriously?
Storing passwords via unsalted SHA-1 is not only unsafe, it’s reckless. When you store user credentials, you have a responsibility to your users to keep their data safe – in this case LinkedIn failed, epicly. Had they bothered to think about security, or hired people that understood even the most basic principles of secure application development – this wouldn’t have happened.
When properly implemented, hashed data shouldn’t be (practically) reversible to its original value – that is, after all, the purpose of hashing. Tweets like this though, make it painfully clear just how wrong LinkedIn got it:
They violated the most basic security principles, but more importantly, they violated their users’ trust.
Update: LastPass has confirmed that they’ll address this issue in the next release.
Update 2: LastPass has addressed this issue in their new v2.0 release. There is still a way to bypass the password prompt in Chrome, but they will address that in the next release. Overall, it looks like we can close the books on this one.
I’m a big fan of LastPass – it’s a great service that has impressed me every step of the way.
Note: This was written in 2012, but not published at the time. The point is still valid, perhaps moreso than ever and deserves to be made publicly. The content has been updated as appropriate, though the core of this article remains intact from the 2012 draft. I would like to note that this doesn’t apply to every environment, there are some where developers are very knowledgeable about security, and write code with minimal issues – my current employer happens to be one of those rare & exciting places.
Anyone working in application security has found themselves saying something like this a thousand times: “always hash passwords with a secure password hashing function.” I’ve said this phrase at nearly all of the developer events I’ve spoken at, it’s become a mantra of sorts for many of us that try to improve the security of applications. We tell developers to hash passwords, then we have to qualify it to explain that it isn’t normal hashing.
So you hash your passwords? Good. Do you salt? That’s good. Do you use a strong hashing algorithm (PBKDF2/bcrypt/scrypt)? Great! But how do you store the hashes? What happens when you get hit with a SQL injection attack?
I’m a big believer in defense in-depth – not that marketing garbage about stacking layers of blinky-light boxes, but using techniques to add extra work for an attacker. You might not be able to stop every attack, but the more work they have to do, the better the odds they won’t get everything they want.
As Shapchat has increased in popularity, I’ve been asked several times to revisit my Snapchat API & Security post, to address the changes that they made in response to my complaints. So, here is it – sorta.
I started making detailed notes and looking at the changes they made – but yesterday @tlack made that mostly irrelevant with his release of Snaphax, a PHP library to interact with the undocumented Shapchat API.
