Slashdot Mirror
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.'"
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)
I think you might be missing the point about duplicate passwords--it's an argument FOR salting the hashes.
Yo dawg, I heard you like the Ackermann function, so OH GOD OH GOD OH GOD
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).
I'll say it again: OpenID.
AccountKiller
I think I will start visiting websites I no longer use, and deactivate my accounts. If that doesn't work, I'll fill the "user profile" with a bunch of nonsense & scramble the password. It worries me that over the last ~20 years I've visited a bunch of places and left behind details about myself. I never used linked-in but I imagine if I did, I'd be in potential trouble now (leaked info).
My AC stalker: " I personally agree with your posts most of the time, but that won't keep me from modding you troll"
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.
https://www.browserid.org/
It's the closest I've seen to SSH Keys. That's all I want, SSH Keys for web auth.
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...).
"The weirdest thing about a mind, is that every answer that you find, is the basis of a brand new cliche" -
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.
So if I crack other people's passwords on Linkedin, can I put that up as a skill in my resume on Linkedin?
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.
If you're looking for hash collisions, you're not going to target a particular hash; you're going to leverage the magic of the birthday paradox and hash your way through a dictionary with passwords listed in order of decreasing probability (with "password" and "12345" listed first, then "p@ssw0rd" and "OU812", etc.) and match the resulting hash with entries in the password file. And you're going to do this once, building one rainbow table, and try it on every unsalted, SHA1 hashed password list you can get your grubby hands on, until you have a nice little dictionary of username / password pairs - and try it on whatever services you're targeting, because most people tend to reuse the same password over and over again (usually Joshua97 or MaryJune05 or some other combination of their kids' names and birthdates).
With all the talk these days about low-sodium diets, they just wanted to provide their users with a healthy alternative.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Don't use his md5crypt and think you did anything useful he says. http://phk.freebsd.dk/sagas/md5crypt_eol.html
Imagine if you weren't allowed to use roads because a bus company complained about your driving 3 times. --skunkpussy
Salting does not make brute forcing one password more work. It does make bruteforcing a list of passwords more work, however.
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.
AccountKiller
No, as he said, we learned to "always salt your passwords," and given a simple example. Then we were told that if we are in a position of authority for an important website, further research and understanding would be required in order to maintain security. You need multiple classes on the topic, not just an hour of instruction. Duh.
Even though salting makes it "much more work", your algorithm could be not CPU(GPU) intensive enough. That's the largest flaw in most systems, and that includes, like the author of MD5crypt stated, too computationally simple to break. So on one simple box, even when salted, we're talking about 2 days time to crack MD5crypt to brute force and 8 character password (probably less with better hardware). Without the salt of course, I suspect that all 6.5M accounts were cracked that day (especially if they can scale it to say 50 ordinary boxes). Use Blowfish or Twofish, and it would take years to even do brute force as each calculation takes in the tenths of seconds (given 12 rounds or greater).
Salting only protects you from precomuted "rainbow" brute force methods which means if you have a big enough table your password is cracked in seconds to minutes rather than oh I don't know what is the average for your typical password? Hour, day..two days? week tops...? Does this difference really mean anything substaintial to the vicitim?
Now I may be wrong, but that would only be the case if the salt was stored with the hashes, correct? Which to me seems rather dumb (from a security perspective, not a performance one). To maximize the benefit of salts, the password hashed and their associated salts should be stored in two different databases, running on different servers so that a hacker would have to compromise both to get access to the list. Lock down the Salt DB server so that's it's only able to communicate with the Hash DB server (and nothing else) and will only return one hash request at a time to it.
Your not really adding security by splitting it up, a well protected server that only stored uuid and salted hashes would do the same.
No sir I dont like it.
Salting only protects you from precomuted "rainbow" brute force methods which means if you have a big enough table your password is cracked in seconds to minutes rather than oh I don't know what is the average for your typical password? Hour, day..two days? week tops...? Does this difference really mean anything substaintial to the vicitim?
To a single victim no. But you've taken the complexity of the problem from hacking a password to hacking 6 million passwords each taking as long. So to the 'average' victim your expectation time before being hacked is 3 million times longer, on a 6 million element set, than one that wasn't salted. There are just over 31 million seconds in a year. So even if your password takes 1 second to crack you've still bought yourself about a month. If it takes a day... well you'll be dead before it's brute forced so who cares.
I only expect to live exactly 50 more years. So if it takes 525.95 seconds to crack my password I have a 50/50 chance of being dead before they manage to brute force it under salting (at 525.95 seconds per they will be able to hack about 3 million in 50 years, and the other 3 million in the next 50 years). If on the other hand it takes 525 seconds for the first one, and small fractions of a second for the next 6 million, I could reasonably expect to have been compromised already.
Actually, they didn't miss just that, they missed the entire story. Honestly, who wrote this? The article SHOULD have said that because they're unsalted, you can get ALL the passwords up to 22 characters turned back into their original text extremely quickly without brute forcing anything. There's no comparison or anything necessary. If they were salted, THEN you'd have to compare them and brute force them. Otherwise you run them all through a rainbow table database on a system with a buttload of RAM and tada, you can reverse them at a very high rate of speed.
So, I already changed my linkedin password.