Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

LinkedIn Password Leak: Salt Their Hide

Soulskill posted more than 2 years ago | from the i-see-what-you-did-there dept.

Security 192

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.'"

cancel ×

192 comments

Sorry! There are no comments related to the filter you selected.

Faulty Logic (0)

History's Coming To (1059484) | more than 2 years ago | (#40259323)

By that argument, because many users use the same password for multiple services then there's no point in hashing passwords in the first place because "somebody else is bound to have a leak". Yes, if you have multiple instances of hash-x then it probably maps to "p433word" or something similar, but that's no reason to roll over and ignore a fairly standard security practice. A statement like this is far more worrying than "Sorry, we screwed up, we're fixing it."

Re:Faulty Logic (5, Insightful)

exploder (196936) | more than 2 years ago | (#40259411)

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

Re:Faulty Logic (4, Informative)

ProDeveloper (2657899) | more than 2 years ago | (#40259427)

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

Re:Faulty Logic (2, Insightful)

Anonymous Coward | more than 2 years ago | (#40259543)

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:Faulty Logic (1)

Anonymous Coward | more than 2 years ago | (#40259777)

Salting does not make brute forcing more work, it makes rainbow tables less useful. This is its primary purpose, though the secondary purpose of hiding matched passwords (which are also likely to be weak passwords) is a convenient bonus.

Re:Faulty Logic (5, Informative)

Goaway (82658) | more than 2 years ago | (#40260095)

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

Salting isn't very valuable any longer (1)

Anonymous Coward | more than 2 years ago | (#40259869)

Salting used to be very important to hide weak passwords from rainbow tables. Now that it takes mere minutes of GPU time to replicate a large rainbow table, salting doesn't buy you nearly as much as it used to. Assuming the attacker gets the salts along with the passwords, but in case of a breach you have to assume they do.

Re:Faulty Logic (4, Insightful)

Vellmont (569020) | more than 2 years ago | (#40260257)

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 [wikipedia.org] 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.

Re:Faulty Logic (2)

tlim (590309) | more than 2 years ago | (#40260415)

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

Standard practice? (5, Insightful)

Anonymous Coward | more than 2 years ago | (#40259361)

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? (3, Insightful)

Nittle (1356899) | more than 2 years ago | (#40259617)

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? (3, Insightful)

Anonymous Coward | more than 2 years ago | (#40259669)

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? (0)

Anonymous Coward | more than 2 years ago | (#40259701)

Does it even matter if someone can log into my bank account or my credit card account online? Sure, they can view my transaction history but it's not like there's a button that allows them to transfer money online.

Re:Standard practice? (2)

PIBM (588930) | more than 2 years ago | (#40259733)

What ? All the banks I've used (3 so far) allows me to transfer money directly from their web site. Yes it can be tracked, but I'm quite sure it can be hard to reverse.

Re:Standard practice? (1)

Doogie5526 (737968) | more than 2 years ago | (#40259853)

All of the banks I've used require 4-5 days, verification, and send email notice (sometimes a post card) when you're transferring to an account for the first time. I'm not saying people should be flippant about their bank login info--but banks seem to do a decent job of notifying users about risky changes to their account (as long as your email isn't compromised, too).

Re:Standard practice? (0)

Anonymous Coward | more than 2 years ago | (#40260733)

Mine (Lloyds TSB UK) requires none of that - but when setting up a payment to a new person they do call your stored phone details and ask you to type in the 4 digits on your screen. The payment then happens straight away. Very convenient for you, but unless a hacker also has your phone you they can't (in theory) do the same.

Re:Standard practice? (1)

SydShamino (547793) | more than 2 years ago | (#40259775)

Have you never noticed the "online bill pay" button on your bank's web site? It makes EFT payments to companies, but, if you want to send a payment to someone without an EFT account, most services will automatically cut and mail a physical check. Anyone who can get into your account and make an online payment can mail a check made out to whatever fake ID they have on hand, or whatever fake-ish company name they set up.

Re:Standard practice? (0)

Anonymous Coward | more than 2 years ago | (#40260289)

When you mail a cheque, it is to some known physical address. Even for a P.O. Box, there is a paper trail.
It is not like you can mail to someone who is wearing a dark suit in the street corner of 5th and Bank on a Tuesday afternoon.

Re:Standard practice? (0)

Anonymous Coward | more than 2 years ago | (#40260803)

But someone did it in Back to the future, are you telling me that is not possible thus making the sequel totally unbelievable/unpossible.

Re:Standard practice? (5, Insightful)

HapSlappy_2222 (1089149) | more than 2 years ago | (#40259797)

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? (2)

TubeSteak (669689) | more than 2 years ago | (#40260197)

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.

Your whole argument fails because LinkedIn isn't "many people".
LinkedIn is a multi-million user networking site for professionals.

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.

LinkedIn has a goddamn team of coders and server monkeys.
Salting your hashes is really really basic stuff. It's at the level of "look both ways before crossing the street."
If you don't look both ways before crossing the street, it's your own damn fault for stepping in front of a car.
And yes, I'm comparing malicious hackers to cars. They will run you over if you give them a chance.

Re:Standard practice? (0)

Anonymous Coward | more than 2 years ago | (#40260581)

If you don't look both ways before crossing the street, it's your own damn fault for stepping in front of a car.

It's your own fault, yes, but it doesn't mean you "deserved" to get hit by the car. That attitude is specifically what the grandparent poster was talking about.

Re:Standard practice? (1)

HapSlappy_2222 (1089149) | more than 2 years ago | (#40260967)

Your whole argument fails because LinkedIn isn't "many people". LinkedIn is a multi-million user networking site for professionals.

Uhm.... I think you may be mis-informed. LinkedIn is simply Facebook for your career. No more and no less. Whether you're linked to highly professional expert and/or leadership types or somebody that flips burgers all day, it's all in the groups and contacts you make.

Because of this, you can be pretty sure not everybody with a LinkedIn account knows proper password selection techniques, or that their chosen professions require this knowledge anyway. Many of my contacts are technical contacts, but many are marketing, sales, production, and management people, too. Limiting my network to people who are in my field doesn't expand my network as much as networking with all of the people I know professionally, so if you're not doing this, you're doing it wrong. We techs seem to love thinking anybody who doesn't know how to protect their online accounts is just plain stupid, but the fact is many people DON'T know these things, and calling them idiots for it doesn't help them learn (and makes you look like a condescending ass in the process).

Of course everyone should be educated in ways to protect themselves, but we, as technical people, should be helping to educate these folks, not being snide about their misfortune after the fact.

LinkedIn has a goddamn team of coders and server monkeys. Salting your hashes is really really basic stuff. It's at the level of "look both ways before crossing the street." If you don't look both ways before crossing the street, it's your own damn fault for stepping in front of a car. And yes, I'm comparing malicious hackers to cars. They will run you over if you give them a chance.

I agree with this statement, including your comparison of a malicious hacker to a car, though I'm confused why you made it in response to my post. Of course we can blame LinkedIn's team for not salting their hashes, but I don't see how this is an argument that supports blaming users for choosing weak or similar passwords for their online accounts. In your analogy, this would be akin to blaming a kid in a stroller (LinkedIn user) for not looking both ways (salting hashes) before his mom (LinkedIn) crosses the street.

In any case, both LinkedIn and their users should learn to do things as securely as possible, and LinkedIn should probably be held liable for any damage caused by their negligence, but the people who's accounts got compromised don't need to hear "I told you so" by a bunch of arrogant neckbeards. In fact, arrogance is hands down the biggest problem I see in this industry, from those who with-hold information to feel superior, to those who blame the "dumbasses" for getting into the situation they're in. I'd rather be a helpful hero than a snide dick, personally, but I guess that's just me.

Re:Standard practice? (2)

ShanghaiBill (739463) | more than 2 years ago | (#40259965)

This is LinkedIn, not your bank, not the government, nothing important.

Many (most?) people use the same id/password combination on multiple accounts. If I know everyone's id/password for Linkedin, then for maybe half those people I can now login to their bank.

People are stupid. Expecting them to be non-stupid is unrealistic. So good security has to accommodate stupidity. That is why even throw-away sites need to have good security.
 

Re:Standard practice? (0)

Anonymous Coward | more than 2 years ago | (#40260337)

In my case, the same email address as userid and password (which is one that I use as a non-critical) was only used in one other place. If "hacked", the person might be able to change my address order some free chips samples for himself.

I have different sets of shared passwords for different classes of accounts.

Re:Standard practice? (1)

brentonboy (1067468) | more than 2 years ago | (#40260979)

This is LinkedIn, not your bank, not the government, nothing important.

Except my bank has security questions that ask would-be infiltrators for personal information about me--the sort of personal information that can be found on LinkedIn, or that contacts on LinkedIn are likely to know.

Re:Standard practice? (5, Insightful)

MobyDisk (75490) | more than 2 years ago | (#40259851)

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? (1)

Bogtha (906264) | more than 2 years ago | (#40260103)

Security and best practices are an academic concepts that are not taught in school.

Best practices aren't academic concepts, they are industry concepts. It's true that there are a lot of cowboys in any industry that don't follow best practices, but that doesn't mean they are "academic".

Re:Standard practice? (1)

Rich0 (548339) | more than 2 years ago | (#40260399)

I wouldn't say that password-hashing is a best practice in my industry. Note, that my industry has nothing to do with making computer software, though it makes a lot of computer software in the process, and buys quite a bit from other companies who have incentive to deliver the features customers are looking for, and not the ones they should be looking for.

If I had to guess I'd imagine that the majority of systems at my company that store passwords do not hash them. At best they encrypt them, which is virtually useless as protection (but good luck explaining that to a PHB).

Re:Standard practice? (1)

Necroman (61604) | more than 2 years ago | (#40260371)

The 2 companies I've worked at were both very security focused. Though, one was big expensive SAN systems (they had been encrypting network traffic since at least 1998 for the device management), and the other company does network security (IPS/IDS) and they are extremely paranoid with how data is stored and transmitted around.

I guess it's a matter of the type of company you work at and the background/enthusiasm of the people you work with.

Re:Standard practice? (2)

MobyDisk (75490) | more than 2 years ago | (#40260597)

To further one of my anecdotes: One of the companies in my list was very paranoid. They used big expensive SAN systems and had been encrypting network traffic forever. They even escrowed customer data they thought they should not hold themselves. Yet they still didn't salt passwords.

I can only conclude that hashing and salting is less well known than encrypting.

Re:Standard practice? (2)

Kyrene (624175) | more than 2 years ago | (#40260461)

I was a contractor at a place where they had an application where there was NO hashing, no encryption, just bare text in the database. When I brought it up to their architect, he informed me that his "philosophy" was that if they were going to hack the database, wouldn't they go after other data than passwords? He refused to believe such a thing would have any validity. It was a very classic case of the stubbornly and willfully ignorant. Glad I'm not there anymore.

Re:Standard practice? (2)

thoth (7907) | more than 2 years ago | (#40260567)

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.

And in turn, corporations don't care about security until is costs them money. Look at Microsoft, they didn't give a flip about security until sometime after Windows XP when that OS was getting owned left and right by malware. Which started to cost them, albeit indirectly.

How exactly will this cost LinkedIn? If it is being ridiculed in the press, they'll just ride it out and not care. If people leave in droves and their service becomes less valuable, or advertisers/customers jump ship, then they'll give a crap.

Re:Standard practice? (0)

Anonymous Coward | more than 2 years ago | (#40260793)

Not quite the same, but I'm dealing with a company at the moment whose proprietary system protocol involves the login prompt (pseudocode):

Server: Send me the MD5 hash of the password
Client: Here's that MD5 hash. See, no-one on the network knows the password!

They don't seem to have ever heard of the concept of a nonce. That MD5 hash is effectively a plaintext password - you never need to know the original password, sending the hash again is enough.

Oh and they store the passwords on their systems in XML plaintext too. The client requests that XML configuration when it connects. Which goes over the network in plaintext. Which makes even the MD5 hash rather pointless?

Re:Standard practice? (3, Interesting)

element-o.p. (939033) | more than 2 years ago | (#40260919)

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

Anonymous Coward | more than 2 years ago | (#40261053)

Indeed, most developers I've talked to have never heard of salting passwords and the few who have heard of it don't do it. I don't think I've ever come into an existing project where passwords were being salted. Typically they were stored in plain text. Obviously this sort of security isn't being taught in many education systems. Not surprising, it wasn't where I went to college and i only picked up on it by reading security related articles.

Re:Standard practice? (1)

steelfood (895457) | more than 2 years ago | (#40260113)

No. Hashing is, but salting is not.

Most people barely understand that passwords need to be hashed, and how to use the hash value. These people certainly don't understand why. If they did, they'd know that salting is important.

There are still plenty of places where passwords are stored in plain text. Sometimes, it's appropriate. Sometimes, it's not. But knowing when is appropriate for what situation is the key, and that's what most people (in general, not just developers and authentication) lack.

Re:Standard practice? (0)

Anonymous Coward | more than 2 years ago | (#40260127)

You'd be surprised how few people "get" security, even in IT, even in the biggest of the big companies. Ask anyone who does business with T-Mobile to hit the recover password option. You get pack your password by SMS via plaintext...

Re:Standard practice? (0)

Anonymous Coward | more than 2 years ago | (#40260221)

It's because they bootstrapped LinkedIn at some point and hired a bunch of subpar indian devs to design security for them on the cheap.

Learned that in Udacity cs253 webapps (1)

Anonymous Coward | more than 2 years ago | (#40259377)

Funny! Learned to "always salt your passwords" in Udacity CS253: Webapps.

Re:Learned that in Udacity cs253 webapps (0)

Anonymous Coward | more than 2 years ago | (#40259625)

You learned a way to salt passwords uniquely for each user so that the salt for the username would be obfuscated but also unique, and that the salt prefix/postfix would provide sufficient entropy to your hash without introducing any mathematical reduction of that entropy (the recent 0day prefix attacks)... in a sophomore level class? Wow.

Re:Learned that in Udacity cs253 webapps (2)

Stickybombs (1805046) | more than 2 years ago | (#40260301)

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.

Ignores the trade off.. (0)

Anonymous Coward | more than 2 years ago | (#40259415)

There is an inherent trade off here, if you store hashed but unsalted passwords then you can use crypto to avoid ever sending the password, or it's equivalent over the network. If you salt your passwords then this is much harder, and generally most people just send the plain text password over the network.

Given the rather poor security of SSL to MIM attacks these days I think I'd rather have passwords exchanged securely over the network than salting.

Frankly, these companies need to do a better job keeping the password hash database separate and secure from the rest of their systems.

Do they understand how hashes work? (-1)

Anonymous Coward | more than 2 years ago | (#40259433)

It is one-to-many, not one-to-one. It is unlikely that you will see a hash collision with the same password string.

Re:Do they understand how hashes work? (5, Informative)

Anonymous Coward | more than 2 years ago | (#40259515)

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.

Re:Do they understand how hashes work? (1)

jellomizer (103300) | more than 2 years ago | (#40259811)

One to Many... But a lot of those Many are characters you are not going to type with your keyboard.

Re:Do they understand how hashes work? (0)

Anonymous Coward | more than 2 years ago | (#40260051)

That *you* aren't going to type with *your* keyboard. I used to have a ^E in my password. (Most modern websites don't support control characters, sigh...)

Re:Do they understand how hashes work? (0)

Anonymous Coward | more than 2 years ago | (#40260419)

What you wrote doesn't make sense...

If you hash the same string again and again using the same hash method you will get the same hash value. That is by design for the standard definition of a hash function and what makes them useful.

If you hash different strings it is unlikely they will result in the same hash... but that likelihood depends on the size of the sting being hashed compared to the size of the hash and the design of the hash method.

How about stop using passwords (3, Interesting)

Galestar (1473827) | more than 2 years ago | (#40259435)

I'll say it again: OpenID.

or BrowserID (4, Interesting)

gQuigs (913879) | more than 2 years ago | (#40259539)

https://www.browserid.org/ [browserid.org]

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

Client Side Certificates already here.... (0)

Anonymous Coward | more than 2 years ago | (#40259867)

You know, you can already have client side certificates that are supported by browsers for quite a long time now.

For examples of sites that use this: startssl.com. They can even be your OpenID provider and you then authenticate with them via client SSL cert. No passwords.

Sadly, slashdot.org OpenID implementation does not seem to work with their authentication. All I get is "server_not_allowed." error. Oh well, I guess I will remain AC :)

Re:How about stop using passwords (0, Redundant)

cpu6502 (1960974) | more than 2 years ago | (#40259585)

What's that?

Re:How about stop using passwords (0)

Anonymous Coward | more than 2 years ago | (#40259947)

Re:How about stop using passwords (3, Insightful)

Anonymous Coward | more than 2 years ago | (#40259679)

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

Re:How about stop using passwords (1)

gbjbaanb (229885) | more than 2 years ago | (#40259793)

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

true, but with more and more reputation-busting exploits like this, you'd think they'd be happy to pass the password-storage problem to someone else. No more "we were hacked and lost all our passwords" news.

Maybe the issue is that they just don't trust the providers to be secure themselves, though if that's the case, it's still better for the site (but not the user).

Re:How about stop using passwords (1)

Galestar (1473827) | more than 2 years ago | (#40260201)

Yes, because so many people are going to jump at the opportunity to use LinkedIn as their provider for their own closed federated login protocol now that theyve been hacked.

Re:How about stop using passwords (0)

Anonymous Coward | more than 2 years ago | (#40259835)

You nerds can say "OpenID", but everyone else in the real world is going to say "Facebook".

Either way, these constant password cracks are going to kill the idea of independent site logins. Users are going to demand a centralized auth provider, and its probably not going to be "open".

Re:How about stop using passwords (1)

jellomizer (103300) | more than 2 years ago | (#40259843)

Correct Horse Battery Staple

Re:How about stop using passwords (0)

Anonymous Coward | more than 2 years ago | (#40259969)

Correct Horse Battery Staple

0bcf1df3cb81df3908d74d46b7fa9dd036b3b3c2

Re:How about stop using passwords (0)

Anonymous Coward | more than 2 years ago | (#40260945)

So you learned nothing from this ordeal? I'd better get some salt with that horse.

Time to start scrambling passwords (2)

cpu6502 (1960974) | more than 2 years ago | (#40259465)

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

Re:Time to start scrambling passwords (3, Informative)

sideslash (1865434) | more than 2 years ago | (#40259655)

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:Time to start scrambling passwords (1)

royallthefourth (1564389) | more than 2 years ago | (#40259855)

...and you don't even hear about when those little sites get breached, if they're even aware of the fact at all.

Re:Time to start scrambling passwords (0)

Anonymous Coward | more than 2 years ago | (#40259681)

Linkedin, unlike Facebook, has nothing but stuff I want on a resume that I send to hundreds a year anyway. The *point* is for your stuff to get leaked and exposed to the world.

Re:Time to start scrambling passwords (1)

SydShamino (547793) | more than 2 years ago | (#40259807)

Like your reputation once your account starts recommending Xtenz to all your contacts?

Re:Time to start scrambling passwords (2)

HapSlappy_2222 (1089149) | more than 2 years ago | (#40259831)

I just hope my "leaked" LinkedIn info gets passed on to a potential overseas employer!! This new "automatic international networking" feature they implemented is going to be GREAT!

Re:Time to start scrambling passwords (1)

MobyDisk (75490) | more than 2 years ago | (#40259863)

I find that very few sites have a deactivate option. I think your backup plan will be the most common approach.

Re:Time to start scrambling passwords (1)

SuricouRaven (1897204) | more than 2 years ago | (#40260673)

If you were to delete your account... it'd probably stay in their database. Got to have something for the advertising statistics table to refer to.

Daft Question (4, Insightful)

rufty_tufty (888596) | more than 2 years ago | (#40259541)

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:Daft Question (0)

Anonymous Coward | more than 2 years ago | (#40260115)

Everybody does it differently. NIH syndrome.

Re:Daft Question (2)

Hotawa Hawk-eye (976755) | more than 2 years ago | (#40260171)

There ARE libraries like that. From the article:

As I said, md5crypt [a hashing function based on MD5] is pretty much the "default" password scrambler for a lot of people, but even though it fulfilled all relevant criteria back in 1995, I no longer consider it safe enough (see: http://phk.freebsd.dk/sagas/md5crypt_eol.html [freebsd.dk] ).

But what was secure back in 1995, when computers had processors like Pentiums or Pentium Pros [wikipedia.org] operating at around 200 MHz, is not secure in 2012, when computer processors in the Sandy Bridge family [wikipedia.org] are operating between 1.6 and 3.6 GHz (1600 to 3600 MHz) and likely have GPUs [wikipedia.org] they can call upon for extra computing power. [My use of the list of Intel processors only is not intended to be a slight against other processor manufacturers, but just the first list I found.]

Resume (5, Funny)

tanujt (1909206) | more than 2 years ago | (#40259553)

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 (5, Funny)

SydShamino (547793) | more than 2 years ago | (#40259841)

You can put it on everybody's resume!

Re:Resume (2)

HapSlappy_2222 (1089149) | more than 2 years ago | (#40259873)

No, but you can steal other people's resumes and append them to your own. Resumes are like sausage or cocktail waitress bustlines; the bigger the better!

Re:Resume (0)

Anonymous Coward | more than 2 years ago | (#40259893)

Yes. You can also use them as your reference.

Re:Resume (1)

AlexB892 (221143) | more than 2 years ago | (#40259905)

Even better, you can put it up as a skill on their resume on LinkedIn!

Re:Resume (1)

K. S. Kyosuke (729550) | more than 2 years ago | (#40259927)

Yes, and preferably put it in their own profiles.

Obese americans (1, Funny)

Anonymous Coward | more than 2 years ago | (#40259629)

Always wanting to salt everything. Maybe LinkedIn just wanted to be leaner??

The significance of LinkedIn (5, Interesting)

sir-gold (949031) | more than 2 years ago | (#40259633)

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:The significance of LinkedIn (2)

steelfood (895457) | more than 2 years ago | (#40260215)

On the flip side, if you don't reuse your passwords, you're never going to remember how to access all 200 sites that require it. Most people barely remember their username, nevermind their password.

There's a bigger problem here than just password reuse. It has to do with passwords as an authentication factor in general.

Re:The significance of LinkedIn (1)

zzsmirkzz (974536) | more than 2 years ago | (#40260539)

On the flip side, if you don't reuse your passwords, you're never going to remember how to access all 200 sites that require it.

That's only if you do it without thinking about it first (i.e. use 200 random passwords). It's very easy to come up with your own system of starting with a base password then add things to the end (or beginning) that makes it unique for the particular site (i.e. using an abbreviation of the site name). You can even do this with different levels of base passwords (in case you are paranoid of a hacker specifically targeting you) one secure and one insecure. If you think that is still hard to remember, you can actually write down the modifications you made to the base word (without writing down the base word) and still be secure (this is usually to conform to ridiculous password requirements that, once published, makes the entire system less secure). It's not hard, it just requires a little thought and prior planning.

Re:The significance of LinkedIn (1)

KernelMuncher (989766) | more than 2 years ago | (#40261043)

Yes but what about sites with stupid developers that limit password size or don't allow special characters (two of the most important aspects of good passwords) ? I've seen plenty of them. In essence you have to dumb down your base password choice to accommodate them. Or remember that for those particular sites you have a short / no special character version of the password. Which you inevitably forget soon after creating the account.

Not exactly (2)

ptrourke (529610) | more than 2 years ago | (#40259641)

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

Re:MaryJune05 (1)

Anonymous Coward | more than 2 years ago | (#40259821)

Phew, close one, my password is MaryJane420.

whats so horrid about it (1)

KingBenny (1301797) | more than 2 years ago | (#40259889)

id put linkedin or any other social networking site on my usual password list where i wouldnt put ebay or PayPal .... what baffles me most is why no one is cashing in on the password gap the risk maybe? the impossibility to secure? so far i never heard of facebook, or microsoft or google being hacked , i wonder what happened to sony still i still suspect some inside penetration there who's gonna make a buck providing the world with that one simple login then? probably some indian or asian guy i guess

Re:whats so horrid about it (1)

KingBenny (1301797) | more than 2 years ago | (#40259959)

the inability to edit is the best and worst part at the same time, its like quantum science, right, schrodingers inability .... yea, they obviously were marketing interim kinda people who thought they saw a gap with no actual idea of how it works, on the other hand, who cares if your linkedin gets hacked, when it comes to PayPal i change my password everytime i pay for something but when it comes to any other site i dont care if it gets hacked since it would be a waste of time, anyone seeing the spam well, i guess maybe i'm just pretty recognizable, who cares man, they failed, no one paid end of story, they suck :-)

low-salt (2)

Megane (129182) | more than 2 years ago | (#40259901)

With all the talk these days about low-sodium diets, they just wanted to provide their users with a healthy alternative.

Others using same passwords (1)

cluedweasel (832743) | more than 2 years ago | (#40259935)

I checked my Linkedin password against the list to see if it was there or not. It turns out it wasn't but I thought I'd change it anyway to be on the safe side. I checked my 2nd, 3rd and 4th choices on the leaked list before changing. All of those were on the list. It surprised me a little because they're not common passwords or particularly obvious. I guess it shows if you get a large enough group of people together, similar though processes are going to lead to similar passwords.

Re:Others using same passwords (0)

Anonymous Coward | more than 2 years ago | (#40260043)

Oh crap, I didn't think about that. Please tell me your password isn't also something like
0n3 d03s n0t s1mplj w4lk 1nt0 mj l1nk3d1n 4cc0unt

Re:Others using same passwords (1)

cluedweasel (832743) | more than 2 years ago | (#40260351)

Of course not. It's p@ssw0rd. Shit! Now I'll have to change it again!

Mental image (1)

ThatsNotPudding (1045640) | more than 2 years ago | (#40259977)

Somewhere, an astute, MBA-sporting LinkedIn user just proudly placed a salt shaker atop of their post-it note of passwords and smugly called it a day.

What difference does it make? (0)

WaffleMonster (969671) | more than 2 years ago | (#40260067)

For the sake of argument assume a database of millions of salted SHA-1 passwords was compromised. What is the effective difference?

These passwords can still be brute force at todays mega ridiculous n core, GPU accelerated rates at extremely low cost. This is only getting worse with each die shrink while human ability to remember complex passwords remain fixed.

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?

Bottom line yer still at substantial risk whether your passwords are salted or not therefore the assumptions and actions taken to mitigate a compromise are the same whether salted or not.

Too many see hashed passwords as secure so they don't take the necessary steps to sufficiently protect their data at rest.

The only acceptable solution to this problem in my view is better security. Use strong reversable encryption on passwords were they are stored. Isolate and control sensitive data, sane key management, operational security...etc. When I hear people say salt the passwords yea great idea ..do it but this really does not fix or solve a damn thing.

It should not just stop with password storage. There is also todays universal yet insane practice of sending plaintexts over SSL.

I would rather see plaintexts or hashes stored in a secure database using mutual knowledge of passwords to establish trust between parties... this would enable zero knowledge systems like SRP to provide mutual authentication including session keys to bootstrap encryption of the session enhancing or replacing SSL with a much better and personal source of trust.

Re:What difference does it make? (2)

zzsmirkzz (974536) | more than 2 years ago | (#40260627)

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.

Passwords? We don't need no stinking passwords! (0)

Anonymous Coward | more than 2 years ago | (#40260133)

The problem seems to lie with websites storing cryptographic hashes where a hacker can get at them, rather than having a system where the computer that stores the hashes can ONLY accept a hash from the server of the website, and that can ONLY output a "YES" or "NO".

This whole thing is like a bank insisting that when you deposit money with them, that you provide your own lock-box for your cash, because their vault isn't that secure.

They make much hay out of the notion that ultra powerful cracking machines can test a zillion bajillion passwords per yoctosecond... but in reality, if a cracker did not have the file with all the password hashes, it could really only try something like 3 attempts per 8 hours, or per day, (before the server locks the account for security) or whatever the settings are, it's usually not designed to allow more than a handful of tries in a while, and hopefully the server would block the IP address of anyone obviously trying this kind of thing.

So our passwords aren't really the problem, unless you're using the Planet Druidia Airshield Password, (1, 2, 3, 4,... 5.) or something similar.

My bank requires a PIN after login, which to me multiplies however many possible passwords there are by 10,000. But the real security is the fact that if you enter that password wrong three times, it stops letting you guess.

To me, the real problem seems to be twofold, that the hashes are vulnerable to being stolen, and that operators of websites, etc., put arbitrary, stupid limitations on passwords. I'm not bitching about having to use at least one upper case, one lower case, etc. etc., I'm talking about one that doesn't let you use every one of the 255 basic ASCII characters, and that limits you to 10 or 12 characters or some other arbitrary thing. They should, I feel, enhance the length, and allow the use of all characters you can get to.

How hard would this password, hashed properly, be to "guess"?

"bo0kshelf stereo span1shb00k clock 1212`~~` "

versus

" bookshelf stereo spanishbook clock 1212"

but most websites I've been to would complain that the password is too long, or wouldn't like the " `~~` " part at the end, or the fact that there are no capital letters. So, while the first password is clearly stronger than the second, isn't the second strong enough? 35 characters, chosen from between a and z, plus the spacebar, plus 0-9. I think that's 37^35 possible passwords, yields about 7.7 * 10 ^ 54 possible passwords. That of course only applies if the password cracker KNOWS that I only used lower case letters and numbers. If you incorporate the possibility of using upper case, etc., symbols, you have about 95 ^ (MAX PASSWORD LENGTH), if you allow passwords of up to say... 128 characters... you end up with passwords that would be trivial to remember, and insanely hard to break. (1.4 * 10 ^ 253 possible combinations...)

So the problem is NOT generally with the user's choice of passwords, it's with the server's inability to keep those damned password hash files secure, and with their policies of insisting on placing arbitrary stupid limits on what can go into a password. Just requiring users to choose 4 or 5 or 7 words at random (or even not really random) without number replacement or symbols would go a long way to fixing the damned problem.

So why not allow users to make their pw's whatever they want, any of 255 characters, such as alt 0208, or "Ã", or whatever, and pick up to 128 of them, including spaces? I think it's because they want to be able to dodge the blame that is theirs for allowing someone to steal the password hash file. No matter how strong the passwords are, if someone gets that hash file, how long it takes to guess the passwords it contains is only a function of how much computer power they can bring to bear against them. With the new computers that keep coming out every few weeks, the password hashes might just about as well be rot-13'ed instead of SHA-256'ed. They'll get them eventually, anyway. Why force users to be responsible for security, when the server operator is?

Re:Passwords? We don't need no stinking passwords! (1)

Anonymous Coward | more than 2 years ago | (#40260545)

Or perhaps the hash method used should make it so it's not possible to guess the length of the password, filling in the password with some collection of characters after password entry. What I mean is, suppose the maximum password length is 128 characters. The user chooses "12345" as a password.

The server takes "12345", then adds "The quick red fox jumps over the lazy brown dogs" over and over until the length reaches 128 characters. So even though from the user's perspective, his password is "12345" the server regards the password as

"The quick red fox jumps over the lazy brown dogsThe quick red 12345 fox jumps over the lazy brown dogsThe quick red fox jumps ove" (if I counted it right...)

and then it encrypts/hashes that, and ends up having your password hash as something like:

"Uj&8Anv0 H6Hfg*ggYly54jbt0Gy0tygvulTY78Jbyi~Mbi=6Bt8p,mYUILMN$InQRup($ylp56vcd%^OKHtOJG7690>J%^^7D3w43swazzZA"

The portion that is the users password is located in the middle, or something similar.

When the user with the "weak" password of "12345" goes to log-in, the password he types in is then hashed to the 128 character garbled string...
he only sees " ***** " in the password field, but what is stored on the server is the long string. Now the customer doesn't have to bring his own strongbox to the bank.

So what? (1)

pubwvj (1045960) | more than 2 years ago | (#40260315)

So a useless site is easily cracked for people who use poor passwords of insufficient length such that they would have the same hash codes. Not a big deal.

Re:So what? (1)

Kyrene (624175) | more than 2 years ago | (#40260483)

Not if you used a random identifier for their salt that's unique to each user, such as their username/email. That's how I create mine.

CANCELED LINKEDIN (0)

Anonymous Coward | more than 2 years ago | (#40260339)

They have cause me to go and change a number of sites.

I tried to contact customer support.

They just send back junk mail.

FURBAR

Resume Posted to Linkedin (1)

wideBlueSkies (618979) | more than 2 years ago | (#40260863)

Experience: Director if IT Security for a large Social Media Product.

Objective: A position where I can apply my experience and lessons learned in a fast paced and dynamic environment, targeting a large customer base. ::Hired:: By Facebook.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?