LinkedIn Password Leak: Salt Their Hide

CowboyRobot writes "Following yesterday's post about Poul-Henning Kamp no longer supporting md5crypt, the author has a new column at the ACM where he details all the ways that LinkedIn failed, specifically related to how they failed to 'salt' their passwords, making them that much easier to crack. 'On a system with many users, the chances that some of them have chosen the same password are pretty good. Humans are notoriously lousy at selecting good passwords. For the evil attacker, that means all users who have the same hashed password in the database have chosen the same password, so it is probably not a very good one, and the attacker can target that with a brute force attempt.'"

Comments

Standard practice?

[Anonymous Coward]

Isnt salting and hashing a standard practice for passwords even for low security stuff?
With something as high profile as Linkedin, how did it get missed?
Arent there audits,etc to check for this type of stuff?
Isnt it similar to releasing a range of cars, all of which have the same key (or something similar. Analogies are my weak point, as is the English language)

Re:Standard practice?

[Nittle]

I think everyone fails to keep this in perspective.
This is LinkedIn, not your bank, not the government, nothing important.
If you use the same password on some bunk website as important things, then you deserve what you had, but if, for some reason, I used the same password for slashdot as LinkedIn, and someone hacks my slashdot, whatever. The thing to really worry about is what these companies do with all of our personal information.

Re:Standard practice?

[Anonymous Coward]

For those with paid Linkedin accounts, linkedin is like any paid service and must be secured appropriately
Even for others, its an important career development resource

Re:Standard practice?

[HapSlappy_2222]

Not taking a jab at you personally, but I've never understood the "you deserve what you got, silly victim!" mentality. No victims *deserve* to be victimized. Sure, they could have taken better steps to protect themselves, but I can just as easily say "you deserve that cancer you got" for not getting regular boob or prostate squashings. It's technically true that many people are vulnerable because they don't know how important it is to protect themselves, but directly blaming them for it is counter-productive.

Education of users is a very, very good goal, especially when so many users don't fully understand the risks out there, but the first step in educating them is having empathy for their plight. Sure, victims learn the most valuable of lessons, but it would far better to have them learn to protect themselves *before* the damage is done.

Re:Standard practice?

[MobyDisk]

Isnt salting and hashing a standard practice for passwords even for low security stuff?

It is.

I have worked for 4 companies where I was involved with a database that contained user passwords. Before I arrived, none of those companies used salts, and only one even hashed the passwords. When I explained it to my fellow programmers, it was the first time they had ever heard of the concept.

Security and best practices are an academic concepts that are not taught in school. Most people don't really care about security until it affects them. Slashdot is an unusual cross-section of people who tend to be security-minded so what appears to be common knowledge here is not representative of the software industry.

Re:Faulty Logic

[exploder]

I think you might be missing the point about duplicate passwords--it's an argument FOR salting the hashes.

Daft Question

[rufty_tufty]

This may well be a very daft question but:
It appears that the default is to use a simple solution when people are first developing their websites.
Isn't this what libraries are for? Why isn't the default secure method in development environments/website template/distros etc to use a much more secure method?
Why is there no standard library that I just say (for example) store_user_password($user_name); and it takes care of it?
If there is such a thing why isn't it more universally used and why blame the website implementers for what is a dev environment/toolkit/whatever problem?
If the technology the article talks about has been known since the 80s why isn't it the standard in all the modern environments? And whatever the answer I'm not sure the blame rests in the users of however they develop this(unless they are writing their website in C based CGI...).

Re:Faulty Logic

[Anonymous Coward]

Or more important, makes it so you would have to try to brute force each one because the hash won't exist in previously generated rainbow tables.

Re:How about stop using passwords

[Anonymous Coward]

Not gonna happen. All big sites want to be OpenID *provider*, but none of them will accept OpenID Logins.

Re:Faulty Logic

[Vellmont]

Both the summary and article are being stupid about the reason for salting in hashed passwords. It's main benefit isn't hiding two same password. It's main purpose is to make brute force much more work,

Yes, but you should also mention that salts with a large amount of entropy also protect against Rainbow tables and other forms of pre-computed hashed passwords. Make sure you have enough entropy in your salt(128 bits is very high) to prevent these kinds of attacks.

I'd recommend a randomly generated salt for each password, and not based on some user details. This guarantees a large amount of entropy in the salt. Some people also recommend an added site wide salt as well that's not stored in the same place as the password (embedded in the code for instance). This might increase your security a bit, but it's going to cost you quite a bit in added complexity.