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:Standard practice?

[element-o.p.]

Security and best practices are an academic concepts that are not taught in school...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.

^^THIS!!!^^

I took a senior-level computer security class while working on my C.S. degree in college, and it was largely a waste of time. We spent half the semester working our way through various historical encryption algorithms trying to get *to* asymmetrical encryption (you know, Caesar's belt, various ROT-x ciphers, etc. -- i.e., stuff that should have been covered in the first week, maybe). We spent most of the rest of the semester dissecting DSA and RSA, and maybe two weeks talking about covert channels. We spent next to no time talking about one-way hashes, and salts were a completely foreign concept to me when I discovered them two or three years later when I started using Linux. As far as best practices for real-world computer security? I don't think that was ever even a FOOTNOTE in any of my C.S. courses.

Maybe I just went to a crappy school, but IMHO, my college education was woefully inadequate for the real world. Pretty much everything I use on a day-to-day basis was learned on my own, outside of college.

Re:Faulty Logic

[exploder]

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

Re:Faulty Logic

[ProDeveloper]

Exactly. 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, even if the user supplied short password. Even Google isn't stupid enough to pull stuff like that. The salt should consist of general site wide salt, and personal salt calculated from user values that do not change (UID, birth date, some extra field in db).

How about stop using passwords

[Galestar]

I'll say it again: OpenID.

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:Do they understand how hashes work?

[Anonymous Coward]

Do they understand how hashes work?

Yes, Poul-Henning Kamp understand how hashes work. Much, much, much better than you do. But if you feel compelled to lecture the writer of MD5crypt on your wonderful insights into how hashes work, please, feel free.

or BrowserID

[gQuigs]

https://www.browserid.org/

It's the closest I've seen to SSH Keys. That's all I want, SSH Keys for web auth.

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...).

Resume

[tanujt]

So if I crack other people's passwords on Linkedin, can I put that up as a skill in my resume on Linkedin?

Re:Resume

[SydShamino]

You can put it on everybody's resume!

The significance of LinkedIn

[sir-gold]

This LinkedIn hack could lead to even more high-profile hacks, due to the unique user base that LinkedIn has

On most sites (like Facebook) most of the stupid passwords will belong to stupid 13 year old kids with nothing of value to hackers, but on a site like LinkedIn you are more likely to get the password for some computer illiterate corporate executive. In many cases this is the same simplistic password he uses at work, where he insisted he be given admin-level access on all of their servers "because hes an executive"

Computer security is always about the weakest link in the chain, and when one of those "links" partied his way though business college and never thinks twice about password reuse, you have a pretty weak chain. LinkedIn is like an x-ray showing the hackers who the weak links are.

Re:Time to start scrambling passwords

[sideslash]

If you've used the same password at multiple sites, you've already exposed yourself to cross-site mischief if one was compromised. LinkedIn looks bad right now, but you know there are a lot of sites that store passwords in plaintext.

Re:Faulty Logic

[Goaway]

Salting does not make brute forcing one password more work. It does make bruteforcing a list of passwords more work, however.

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.