6 ms·

"We were curious what would happen to our share price if our company did something incredibly stupid" The above comment might seem incredibly harsh, but really

by Smerity 14y ago

"We were curious what would happen to our share price if our company did something incredibly stupid" The above comment might seem incredibly harsh, but really, there's no good excuse for a site this prominent to not have a salted, secure password hashing system. Even if they started with an unsalted password system, users can be migrated to the newer more secure system on next login. The only way I could regain respect for LinkedIn is if we find that these unsalted hashes were from users who never logged in to LinkedIn after the security upgrade. From the replies of other HN users who have found their password hashes in the leaked list, this doesn't seem to be the case though. I can understand database leaks. Bad things happen. Not being prepared for such an event however is where I draw the line. These leaks impact users far beyond just the site at fault. It's not enough to say users should use LastPass. They don't, and that's the world we live in, for better or worse. If computer security doesn't take into account problematic users, then it's flawed computer security.

pixelcort 14y ago
Regarding requiring users to log in; wouldn't it be better to run their current hash through another password hashing scheme (while we're at it bcrypt, scrypt, PBKDF, etc)? Then, the next time they log in, verify them by running their password through the old algorithm, and the result through the new one.
- deleted 14y ago
  [deleted]
- Cushman 14y ago
  That could be a good transition strategy if you're worried about being compromised before all your users have logged in again, but you would still want to move them over to using just the new system when they do. It probably would be fine, but when it comes to crypto you don't take chances when you don't have to.
- peteretep 14y ago
  Yep. Here is a treatment of that: https://gist.github.com/1051238 https://gist.github.com/1051238
Jabbles 14y ago
Surely just hashing the username|password would massively reduce the effectiveness of leaks like this? Sure, a hacker would know what the "salt" is, but since it now varies between users you would expend the same amount of effort breaking one person's login as you previously would spend breaking everyones (on average). (Not recommending it, just wondering if my reasoning is correct.)
- ricardobeat 14y ago
  Please don't downvote posts like the parent. It's a legitimate comment, asking a question, if you have something to say please reply.
- LinXitoW 14y ago
  It would make it a lot easier for LinkedIn to identify whose hashes were leaked because with a salt, all passwords would be unique. It would also make rainbow tables useless. But in this day and age, the bigger problem is how fast you can compute the hashes, salt or no. With GPUs you can calculate a few hundred million(depending on the hashing algorithm) per second, making the algorithm used the real vulnerability. Best practice involves increasing the calculation time of you're algorithm. Theoretically, you could just rehash y few thousand times in a loop, throwing in a salt here and there, but practically, you should just use bcrypt or scrypt.
  - darkarmani 14y ago
    A few hundred million? Try in the billions. Like 33.1 Billion/s for md5. http://blog.zorinaq.com/?e=42 http://blog.zorinaq.com/?e=42 This is why you don't use really fast hashes for passwords and you iterate (key stretch). Bcrypt like you said.
- Smerity 14y ago
  I hear this commonly, so it is a good idea to clear it up. Usernames have lower entropy than a random salt and are predictable in many cases. People re-use usernames and some usernames are common. If your password system became common on the web, or if I knew the workings of your password system (i.e. open source / leaked codebase / Kerckhoffs's principle[1]), I could generate a rainbow table for either common or targeted users. This means I could generate a rainbow table for "Jabbles", gain access to your password and compromise your account before the website is likely even aware of a breach or has time to warn you. Salts only act to slow down, not prevent, compromising leaked password hashes (as you can always brute force which is quite practical with MD5/SHA1). Thus, using a username defeats one of the stated purposes of salting. It's also said ad nauseam (with good reason) but rolling your own in security is a bad idea, especially when libraries exist that do exactly what you'd intend to do just as easily. Algorithms such as bcrypt and scrypt exist and are well vetted. bcrypt is easy to integrate with many languages and provides a trivial interface and sane defaults for iterations/rounds [brute force] and salts [rainbow table]. bcrypt can also handle increasing the security of your system over time as the metadata is stored as part of the hash. tl;dr Using a username for salting means a targeted attack against a single or small number of users would be damn near impossible to stop as the second they have the password hashes they also have the passwords. [1]: http://en.wikipedia.org/wiki/Kerckhoffs%27s_principle http://en.wikipedia.org/wiki/Kerckhoffs%27s_principle
ricardobeat 14y ago
We've just checked everyone's passwords around the office. One of them was in the list, and he has accessed the site the past month.
- tg3 14y ago
  Could be that he shared a password with another account that hasn't? Wishful thinking most likely.
jcdavis 14y ago
What do you recommend users do instead? Unfortunately there will probably always be websites storing passwords in unsecure ways. I mean I'd certainly rather not have to deal with the hassle (however small) of using LastPass, but as you said, that's the world we live in. Hoping for competence by the writers/maintainers of websites is also flawed computer security, is it not?
- Smerity 14y ago
  Hoping for competence is indeed flawed from both sides. I would hope users use distinct, random passwords for each site they visit and that developers store those passwords in a safe secure way. I also assume both sides won't listen to logic however :) The reason I'm annoyed with this particularly is that larger sites are more likely targets due simply to their size. Larger sites generally have the developer resources to provide a good solution to the problem from their end but commonly don't. This makes them look bad and means their users are left in more danger than before. No-one wins.
seats 14y ago
>> Even if they started with an unsalted password system, users can be migrated to the newer more secure system on next login. In thinking about this, I wonder if in that scenario you'd even have to wait until next login. You could just use the weak hash as the input to your salted hash function and keep a flag of whether or not you need to 'pre-hash' the password before using your v2.0 salted hash. As users log in you could replace slowly replace the double hashed entries with single salted hash versions and flip the flag.
nohat 14y ago
Perhaps the worst part is that they either didn't know about the breach (likely), or didn't tell anyone (hopefully not).
deleted 14y ago
[deleted]
deleted 14y ago
[deleted]

by Smerity 14y ago

pixelcort 14y ago

Regarding requiring users to log in; wouldn't it be better to run their current hash through another password hashing scheme (while we're at it bcrypt, scrypt, PBKDF, etc)? Then, the next time they log in, verify them by running their password through the old algorithm, and the result through the new one.

deleted 14y ago
[deleted]
Cushman 14y ago
That could be a good transition strategy if you're worried about being compromised before all your users have logged in again, but you would still want to move them over to using just the new system when they do. It probably would be fine, but when it comes to crypto you don't take chances when you don't have to.
peteretep 14y ago
Yep. Here is a treatment of that: https://gist.github.com/1051238 https://gist.github.com/1051238

Jabbles 14y ago

Surely just hashing the username|password would massively reduce the effectiveness of leaks like this? Sure, a hacker would know what the "salt" is, but since it now varies between users you would expend the same amount of effort breaking one person's login as you previously would spend breaking everyones (on average). (Not recommending it, just wondering if my reasoning is correct.)

ricardobeat 14y ago
Please don't downvote posts like the parent. It's a legitimate comment, asking a question, if you have something to say please reply.
LinXitoW 14y ago
It would make it a lot easier for LinkedIn to identify whose hashes were leaked because with a salt, all passwords would be unique. It would also make rainbow tables useless. But in this day and age, the bigger problem is how fast you can compute the hashes, salt or no. With GPUs you can calculate a few hundred million(depending on the hashing algorithm) per second, making the algorithm used the real vulnerability. Best practice involves increasing the calculation time of you're algorithm. Theoretically, you could just rehash y few thousand times in a loop, throwing in a salt here and there, but practically, you should just use bcrypt or scrypt.
- darkarmani 14y ago
  A few hundred million? Try in the billions. Like 33.1 Billion/s for md5. http://blog.zorinaq.com/?e=42 http://blog.zorinaq.com/?e=42 This is why you don't use really fast hashes for passwords and you iterate (key stretch). Bcrypt like you said.
Smerity 14y ago
I hear this commonly, so it is a good idea to clear it up. Usernames have lower entropy than a random salt and are predictable in many cases. People re-use usernames and some usernames are common. If your password system became common on the web, or if I knew the workings of your password system (i.e. open source / leaked codebase / Kerckhoffs's principle[1]), I could generate a rainbow table for either common or targeted users. This means I could generate a rainbow table for "Jabbles", gain access to your password and compromise your account before the website is likely even aware of a breach or has time to warn you. Salts only act to slow down, not prevent, compromising leaked password hashes (as you can always brute force which is quite practical with MD5/SHA1). Thus, using a username defeats one of the stated purposes of salting. It's also said ad nauseam (with good reason) but rolling your own in security is a bad idea, especially when libraries exist that do exactly what you'd intend to do just as easily. Algorithms such as bcrypt and scrypt exist and are well vetted. bcrypt is easy to integrate with many languages and provides a trivial interface and sane defaults for iterations/rounds [brute force] and salts [rainbow table]. bcrypt can also handle increasing the security of your system over time as the metadata is stored as part of the hash. tl;dr Using a username for salting means a targeted attack against a single or small number of users would be damn near impossible to stop as the second they have the password hashes they also have the passwords. [1]: http://en.wikipedia.org/wiki/Kerckhoffs%27s_principle http://en.wikipedia.org/wiki/Kerckhoffs%27s_principle

ricardobeat 14y ago

We've just checked everyone's passwords around the office. One of them was in the list, and he has accessed the site the past month.

tg3 14y ago
Could be that he shared a password with another account that hasn't? Wishful thinking most likely.

jcdavis 14y ago

What do you recommend users do instead? Unfortunately there will probably always be websites storing passwords in unsecure ways. I mean I'd certainly rather not have to deal with the hassle (however small) of using LastPass, but as you said, that's the world we live in. Hoping for competence by the writers/maintainers of websites is also flawed computer security, is it not?

Smerity 14y ago
Hoping for competence is indeed flawed from both sides. I would hope users use distinct, random passwords for each site they visit and that developers store those passwords in a safe secure way. I also assume both sides won't listen to logic however :) The reason I'm annoyed with this particularly is that larger sites are more likely targets due simply to their size. Larger sites generally have the developer resources to provide a good solution to the problem from their end but commonly don't. This makes them look bad and means their users are left in more danger than before. No-one wins.

seats 14y ago

>> Even if they started with an unsalted password system, users can be migrated to the newer more secure system on next login. In thinking about this, I wonder if in that scenario you'd even have to wait until next login. You could just use the weak hash as the input to your salted hash function and keep a flag of whether or not you need to 'pre-hash' the password before using your v2.0 salted hash. As users log in you could replace slowly replace the double hashed entries with single salted hash versions and flip the flag.

nohat 14y ago

Perhaps the worst part is that they either didn't know about the breach (likely), or didn't tell anyone (hopefully not).

deleted 14y ago

[deleted]

deleted 14y ago

[deleted]