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

Faulty Logic

[History's Coming To]

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

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

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:Faulty Logic

[Anonymous Coward]

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

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

Re:Faulty Logic

[tlim]

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

Re:Faulty Logic

[slashmydots]

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.

Re:Faulty Logic

[WaywardGeek]

This point about making password hashing take a whole second is critical. For some reason, the geniuses in charge of our Internet security are totally screwing this up. Take my GPG private key, for example. I have to encrypt the damned thing with a humongous pass phrase, because some dork, who you would expect to know something about security (having written GPG), didn't bother making the private key's decryption key a compute intensive hash of my pass phrase. This allows attackers to do efficient brute-force attacks on our PGP private keys. They don't even have to run the compute intensive RSA algorithm... they just do AES with their password guess and detect if it's correct instantly, because GPG goes to the trouble of providing an instant "Your guess was correct" feature. Worse, sites like github not only allow, but require these insecure PGP keys to be used to log into their systems, even though they have no control over what, if any, password is protecting the user's private keys. I just got a private key from a rather good IT guy recently, and the file was named "ThePasswordIsFoo"! I used to encrypt my freaking OpenVPN keys with a password designed to give you an RSI injury, but the new IT policy is to leave it unencrypted on every Windows machine! And I thought our old SSH on port 22 was scary (actually... that is pretty damned scary). This same problem is true of encrypted documents. The most secure document encryption software I currently know of is my own stupid little tinycrypt algorithm. Do you use encfs, or TrueCrypt? Don't count on any CPU intensive hashing to protect your password. Brute force away!

Instead of leaving your documents wide open to brute force attacks like GPG using Blowfish or AES, it uses the old broken WEB encryption algorithm, RC4, with only a tiny mod: it drops the first 768 bytes of the key stream, which last I checked means no one knows any useful attack against it. It salts the encrypted file with a random 20 byte nonce, and requires about 1 second to compute the hash of the user's password used to do the encryption. Why should average non-security geeks like me have to write our own encryption software for documents, and live with 20+ character passwords on everything that uses GPG? Couldn't we at least count on GPG to get it right?

On top of all that, I run freaking Windows, meaning that I have no clue what software is sniffing for my passwords. I'm careful about what I install, but I installed ZIP, for example, a clear nasty piece of spy/annoy-ware, and Skype, one of the worst security leaks in history. God forbid that I install a free game or anything really stupidly dangerous. I sure hope all those laptops employees carry back and forth from home don't have any dangerous exe files installed :-P A couple friends who actually study security technology rave about the security tech in Windows. But I still press the "Yes" button on that freaking "Allow this program to make changes to your computer" dialog multiple times a day.

What a mess! So, let's drag freaking Linked-In over the coals! Then, let's have a quick look in the mirror. GPG, hears looking at you! Windows... let's not even go there. Mt Gox... really?

Re:Faulty Logic

[Xenna]

Hmm, funny, that's exactly how I described my system last wednesday in an earlier thread on the subject. The added complexity is not a problem at all, the extra password is only stored in the authentication server (which runs on a different system than the database contaning the hashed passwords.

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?

[Anonymous Coward]

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?

[PIBM]

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?

[SydShamino]

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?

[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?

[Doogie5526]

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?

[ShanghaiBill]

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?

[Bogtha]

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?

[steelfood]

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?

[Anonymous Coward]

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?

[TubeSteak]

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?

[Anonymous Coward]

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.

Re:Standard practice?

[Anonymous Coward]

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?

[Anonymous Coward]

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?

[Necroman]

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?

[Rich0]

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?

[Kyrene]

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?

[thoth]

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?

[Anonymous Coward]

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?

[MobyDisk]

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?

[Anonymous Coward]

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?

[Anonymous Coward]

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?

[Anonymous Coward]

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?

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

[HapSlappy_2222]

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?

[brentonboy]

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?

[Anonymous Coward]

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?

[blueg3]

I think everyone fails to keep this in perspective.
This is LinkedIn, not your bank, not the government, nothing important.

That argument might hold water if salting user passwords was difficult, expensive, or not commonly-known best practice. (All of which really translate to "expensive" -- either in developer time or server resources.) Then you'd have a justification -- a low-security site is expending less effort on security. But it's not. It's simple, it's cheap, and anyone who is allowed to make a password database should already know that it needs to be done.

Re:Standard practice?

[Anonymous Coward]

I never give security questions the kind of thing they ask for. If they want my mother's maiden name, they might get "Cheverolet Caprice" (a car I have never owned), or the name of the neighbors's dog that I hate. I really doubt that they are going to check to see if I gave a valid name.

Re:Standard practice?

[Anonymous Coward]

You are so stupid! First you post using your real name and then tell the intarwebz what bank you use! Social Engineering is about to happen to YOU!

Re:Standard practice?

[durdur]

Half the trouble I had as a security developer was trying to educate/convince other developers that making an effort in this area was necessary. Some of them weren't familiar with the basic concepts, but even they were, it's hard to drive home the idea of defense in depth. There is a tendency to think that if the information is inside your database, or behind your firewall, or protected by other means, then it's not worth spending a lot more effort in additional protection. But of course, you are one exploit away from having an intruder inside your database, behind your firewall, etc.

Re:Standard practice?

[Anonymous Coward]

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

You would think so, it's such obvious good practice and so easy that you'd think everyone would do it.

But a lot of sites use plain-text passwords. Great.

So it's good practice, but unfortunately not standard practice.

Re:Standard practice?

[Anonymous Coward]

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.

The comparison is stupid as fuck. You can't blame users for not picking a different 30 characters alphanumeric password with special symbols for every single site they visit. You can't expect every user to use KeePass either. The password system is broken, and it's definitely not the users' fault that LinkedIn devs can't code for shit. It might be their fault to use the same password everywhere, but that doesn't mean they deserve what they got (what a fucking dumb statement).

Re:Standard practice?

[nitehawk214]

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)

Just because something is standard practice means it is followed. It seems to me like security practices are the first to be thrown out because "well none of the users will notice it anyhow." Best security is to assume you are going to get hacked or suffer data theft and design the system such that nothing critical can be gleaned from looking at a simple dump of the database. The fact that they got caught on something so horrifically basic is inexcusable.

The CTO should probably be updating his resume. Oh sorry it is on LinkedIn and his account was broken in to and his work history was replaced with "I AM A DUMBASS".

And before someone comes in with "nobody expects the CxO level to know this crap"; if you are at that level you don't get to pass the buck. Outside security verification by professionals is crucial for any system of this size.

Re:Standard practice?

[Anonymous Coward]

Sounds like you went to a crappy school. I was taught password hashing every semester for the last four semesters of my undergraduate career. Not that any of my peers came out knowing anything, but that was their own failing. Not the school's.

Re:Standard practice?

[rthille]

My security question answers are randomly generated, twelve char alpha-numerics, just like my passwords (like, but different), unique for every site. It can be a PITA, but given the lousy security on sites I use, keeping them separate as much as possible just seems like a good idea.

Re:Standard practice?

[brentonboy]

I never give security questions the kind of thing they ask for. If they want my mother's maiden name, they might get "Cheverolet Caprice" (a car I have never owned), or the name of the neighbors's dog that I hate. I really doubt that they are going to check to see if I gave a valid name.

Actually, I do this too. But I'm betting a lot of LinkedIn users don't.

Re:Standard practice?

[mopower70]

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.

Would you feel better if I said you "earned" being victimized? You smoke two cartons of Camels a week in this day and age, and you don't just deserve cancer, you earned it. You evidently put a lot of effort into pretending that the fact that your cancer was all but inevitable somehow didn't apply to you. Enjoy your winnings!

Re:Standard practice?

[anethema]

It is like winning the lottery! But the odds are better. And instead of money you get, you know, cancer. Woo!

Re:Standard practice?

[Anonymous Coward]

Don't believe the post above!
I'm the _real_ Nittle, he stole it from me.

Re:Standard practice?

[Anonymous Coward]

"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 guess they print out checks and send them via snail mail?

My bank credits the receiving account the same second I press the transfer button.

What do they do if you _call_ them to do an operation?
Do you have to fax in a photo with a newspaper from that day?

Re:Standard practice?

[Algae_94]

People need to stop password reuse. Usually the first argument against that is inability to remember a different password for every site. My solution to that is a variation on password reuse. Use the same base password and come up with your own "salt" algorithm that combines your base password with the sites name (not simply adding the site name to the end of your password, but even that would work) to come up with the unique site password.

Re:Standard practice?

[Johann Lau]

When I learned about salts, I instantly implemented that in my own CMS, the one which nobody but me even uses, while feeling kinda stupid for having used a simple hash previously.

So much for bragging, now for a question: Today I learned about PBKDF2, but I'm not sure if there is any difference/advantage to a custom function like the one I have:

function hash_encode($string, $salt, $hashfunc, $iterations)
    {
        $string1 = hash('sha512', $salt, true) . hash('whirlpool', $string, true);
        $string2 = hash('whirlpool', $salt, true) . hash('sha512', $string, true);
        for($i = 0; $i < $iterations; $i++)
        {
            $string1 = hash('whirlpool', $string . $salt . $string2, true);
            $string2 = hash('whirlpool', $string . $salt . $string1, true);
        }
        $string = hash('whirlpool', $string . $salt . $string1 . $salt . $string2, true);
        $hash = hash($hashfunc, $string, true);
        return $salt . $hash;
    }

If there's some huge flaw in the above, I'd be very grateful if someone could point that out :)

Re:Standard practice?

[b4dc0d3r]

They need to stop password reuse, but they won't. Users do not get paid for choosing passwords, but coders do get paid for writing code. If coders do their job poorly, blame lies with the coders. Expect stupidity, allow for genius.

I'm paranoid enough that I make up fake answers for security questions, and password hints are intentionally misleading, while still enough for me to figure out what it means. I also do not re-use passwords.

But I am not normal. That is why, when I have to write some sort of authentication, I assume the user is a complete and utter tool, incapable of reading or understanding any information or suggestion. At the same time, I also assume they are clever enough to want to defeat my clever scheme of forcing them to be smarter. "Don't reuse passwords" becomes "I must ensure that if a user does re-use passwords, I keep them as safe as I can."

Re:Standard practice?

[Anonymous Coward]

the hash function is usually:

h = sha512($salt . $string);
for(i = 0; i < iterations; i++) {
      h = sha512(h);
}
return($salt . $h);

What you have looks like it is probably ok.. but the above is standard and simpler/easier to maintain.

Re:Standard practice?

[1s44c]

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.

Most likely they hired a bunch of subpar indian developers to put the site together and they didn't even consider security.

Re:Standard practice?

[Walczyk]

Public access websites are different than a corporation's internal network, and should be held to higher security standards due to their visibility and fallout if they do get hacked. After working in IT departments at a few companies I have the feeling that the majority of companies have little to no security prevention, they just expect that nobody will be interesting in hacking their databases. It is so much more profitable to sell data to the Chinese.

Re:Standard practice?

[Anonymous Coward]

Or is it that employers tend to trust employees a tad more than they should?

Re:Standard practice?

[TranquilVoid]

I'll admit web apps are not my area, but to me he had a semi-valid point. For all this talk about ensuring uncrackable hashes, the point of the password is usually to get to the data. If they can access the database to get the hashes they can probably obtain the data directly. Perhaps there are architectural designs that stop this, or the size of the full data is prohibitive to transfer, as I said this is not my area.

Of course there are reasons why you might want the password too such as identify theft and undetected access to future data. Also, using hashed passwords will give some protection against corruption by your own employees.

Learned that in Udacity cs253 webapps

[Anonymous Coward]

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

Re:Learned that in Udacity cs253 webapps

[Anonymous Coward]

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

[Stickybombs]

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.

Re:Learned that in Udacity cs253 webapps

[Anonymous Coward]

Just saying even a basic class on web applications explained to salt passwords. Of course there are other considerations one needs to make when doing work to security any website/system. No flame here but thanks for being the "salt" in the wound and pointing out the obvious.

Re:Learned that in Udacity cs253 webapps

[Sir_Sri]

Web development and security is a 2nd or 3rd year class. You only get 4 years before you're expected to go off and be able to work on any reasonable system. Developing a new salt or hash algorithm is a 4th year and grad school problem, knowing how to use them is 2nd or 3rd (depends on your school and where it fits with other courses).

For my undergrad web development was a 3rd year course (so they assumed you knew data structures already, but that could have been second semester of second year too). Security was a 3rd year topic as part of networking. 4th year networking was advanced topics that would prepare you to know what academic journals to read to do research in the area or keep up to date with it. We also had the students build a real mobile project for the university at a 4th year level. Web development and how to use salting and hashing algorithms is definitely only a 2nd or 3rd year level problem.

Re:Learned that in Udacity cs253 webapps

[leenks]

You only get 4 years before you're expected to go off and be able to work on any reasonable system.

My attitude was that I had 4 years to learn enough to be in a position where I could start to learn how to work on a reasonable system. 12 years on and I still feel like a rookie.

Maybe I should just give up and pick grapes instead?

Ignores the trade off..

[Anonymous Coward]

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.

How about stop using passwords

[Galestar]

I'll say it again: OpenID.

Re:How about stop using passwords

[cpu6502]

What's that?

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:How about stop using passwords

[gbjbaanb]

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

[Anonymous Coward]

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

[jellomizer]

Correct Horse Battery Staple

Re:How about stop using passwords

[Anonymous Coward]

http://lmgtfy.com/?q=openid

Re:How about stop using passwords

[Anonymous Coward]

Correct Horse Battery Staple

0bcf1df3cb81df3908d74d46b7fa9dd036b3b3c2

Re:How about stop using passwords

[Galestar]

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

[Anonymous Coward]

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

Re:How about stop using passwords

[Culture20]

Correct Horse Battery Staple

0bcf1df3cb81df3908d74d46b7fa9dd036b3b3c2

Well sure, if you know what to compute ahead of time, it's easy to get the hash. That's the point of a hash. But how long does it take to get to that hash even if you know that the user is typing only four distinct words?
Aachen Aachen Aachen Aachen
Aachen Aachen Aachen Aachen's
Aachen Aachen Aachen's Aachen
Aachen Aachen Aachen's Aachen's
...
Aaliyah Aaliyah's Aachen Aachen
...
aardvark aardvark Aardvark Aachen
... ... ...
Correct Horse Battery staple
Correct Horse Battery Staple

$ wc -l /usr/share/dict/words
98569 /usr/share/dict/words
$ wc -l /usr/share/dict/words
234936 /usr/share/dict/words
And those don't include changes in capitalization or intentional misspellings. 234936^4 > 80^8 80^11 approaches 234936^4, but even 234936^4 passwords are easier to remember than most of the ones that would fall under 80^8 or higher. Don't arbitrarily limit to only 4 words, and you've got an explosion of memorable phrases. The only bad thing about them is typos and shoulder surfing.

Re:How about stop using passwords

[MikeBabcock]

I'll one-up you on that -- client-side browser certificates have been possible since the first days of SSL on the Internet.

Why aren't we using them to authenticate users and completely secure a link?

Re:How about stop using passwords

[Anonymous Coward]

It's not practically viable, at least for most people in the current state-of-the-art. You don't want to transfer your certificate on any machine you'd possibly use to sign in your account. You could imagine usb sticks containing your certificate, probably encrypted so that getting access to your accounts is not as easy as stealing the stick from you. As security would become synonymous to selling memory sticks, every company will want to sell a different one, claiming that theirs is better and safer to sell more. Then there will be new protocols, then you'd like every website/browser/application to be compatible with every protocol, and so on.
Also, you lose your certificate (disk crash, usb stick stolen, fire, or simply accidental removal...), what happens?
And anyway, in practice, most people won't accept to use an usb stick for their daily logins, even if we manage to get everyone educated enough about the general security problem.
That's why I don't understand how Yubikey has got any popularity. It's fun and geeky, but it has all the disadvantages I can think of for that kind of solution, except you have to trust a company centralizing your data.

Re:How about stop using passwords

[Anonymous Coward]

Why would I want to trust all my security credentials to a single point of failure?
Hell, why would I want to use the same identity on all sites?

Re:How about stop using passwords

[Galestar]

Hell, why would I want to use the same identity on all sites?

Noone says you need to use the same identity on all sites (or that you can only have one OpenID).

Time to start scrambling passwords

[cpu6502]

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

[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:Time to start scrambling passwords

[Anonymous Coward]

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

[SydShamino]

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

Re:Time to start scrambling passwords

[HapSlappy_2222]

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

[royallthefourth]

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

[MobyDisk]

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

[SuricouRaven]

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.

Re:Time to start scrambling passwords

[Sir_Sri]

That's problematic, but everyone getting those messages will realize you got hacked anyway.

I apparently had a windows live account that got hacked. Not really sure when, not really sure how since I don't recall having used it for years. it sent out some spam before MS shut it down and some friends where kind enough to let me know it was sending out stuff. Everyone was well aware that the account was hacked, and to most people its not obvious if its your fault you got hacked or the fault of the site owner.

Re:Time to start scrambling passwords

[1s44c]

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

And I'll bet some of the big ones.

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

Re:Daft Question

[Anonymous Coward]

Everybody does it differently. NIH syndrome.

Re:Daft Question

[Hotawa Hawk-eye]

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

But what was secure back in 1995, when computers had processors like Pentiums or Pentium Pros operating at around 200 MHz, is not secure in 2012, when computer processors in the Sandy Bridge family are operating between 1.6 and 3.6 GHz (1600 to 3600 MHz) and likely have GPUs 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.]

Re:Daft Question

[InvisibleClergy]

There are a lot of libraries. Some of them are simple, and some aren't. Most developers probably don't know which library would be easiest to drop in. So, it's easiest for them to just use the md5() function or something like that. Especially because library developers usually have no sense of when their library is simple or when it's complex.

I can't tell you how many times I've just implemented something for which a library already existed. And it probably took longer than using the library would have, but I feel like I gained a better understanding of the procedures in question.

Re:Daft Question

[shutdown -p now]

This still sounds like a weak argument. Heck, even PHP has single-call salted hashing with Blowfish these days. The problem is poor education - developers don't even know what hashing and salting is, or why it's important for passwords, so they don't even bother to look up how to do it right.

Re:Daft Question

[Sir_Sri]

Or they did that in 2002, to launch a website in 2003, and have no idea how to transition a hashed password database from one system to another, which is a more difficult problem.

The thing is: we still don't know where this hack is from. 6.5 million of 160 million is a very small set of the data. Are *all* linkedin passwords SHA1 with no salting? If so changing your password doesn't do a whole lot of good, and that's a huge disaster for the whole outfit. Is one of their services (say LinkedIn syria) using SHA1 but no where else? (If you're an american linkedin user and found a SHA1 of your password on the list that just means you happen to have the same pwd as someone in syria then).

is this all accounts that haven't changed passwords since 2003? Or whenever they implemented something else? All users who created accounts using a mobile? Etc. The slew of possibilities of what these passwords are is pretty endless. If it's just random grab of 6 million people who happened to log in at some point that's a serious problem because it means all the passwords are unsalted. If it's a specific set of users then we can start to understand when and how this mistake was made - if it was a mistake at all. LinkedIn could very deliberately use SHA1 without salting for all users from Syria or russia or something. I'm not really sure why unless it has to do with cryptography export rules, but that would be a valid reason then.

Re:Daft Question

[WuphonsReach]

Or they did that in 2002, to launch a website in 2003, and have no idea how to transition a hashed password database from one system to another, which is a more difficult problem.

If you design things properly, not hard at all.

Basically, all hashes in the database should be stored in the format of:

$id$salt$encrypted

"id" is a code that tells you which hash was used. You can use the standard "crypt" identifiers, or make up your own if those aren't good enough.

"salt" is the unique salt for each user. Crypt allows for up to 16-character salts, drawn from the [a-zA-Z0-9./] set (64 possibles per position, total of 96 bits possible.

"encrypted" is the resulting hash.

That means that if you decide to upgrade your security by using a newer, fancier hash, you can do so in a transparent manner. The old hashes continue to work unless you specifically decide to break them and force users to enter a new password. But any new password updates can automatically update to the new hash system.

Oh look, that means the following phrase is appropriate:

Those who do not understand Unix are condemned to reinvent it, poorly.

(Learn from those who have gone before.)

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!

Re:Resume

[HapSlappy_2222]

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

[Anonymous Coward]

Yes. You can also use them as your reference.

Re:Resume

[AlexB892]

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

Re:Resume

[K. S. Kyosuke]

Yes, and preferably put it in their own profiles.

Obese americans

[Anonymous Coward]

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

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

[steelfood]

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

[zzsmirkzz]

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

[KernelMuncher]

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.

Re:The significance of LinkedIn

[indeterminator]

Sounds complicated. Why not just use password reset every time you need to get in?

Re:The significance of LinkedIn

[Anonymous Coward]

But if you end up with a scheme that creates a password like P00dlebarnlinkedin, the hacker who compromises your linkedin password is going to have a good guess at what your Facebook password will be.

Re:The significance of LinkedIn

[Pope]

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.

That's what Keepass and 1Password are for.

Re:The significance of LinkedIn

[Anonymous Coward]

And what about stupid programmers that require that the password includes numbers or does not start with a number or all sorts of other requirements inorder to make the password stronger. But in the process these kinds of schemas don't fit your base password or password modification schema and so make you write down the password.

The same is true for all systems that require you to change the password frequently. It forces you to write them down as you can't remember which one you used where and when.

Re:The significance of LinkedIn

[SpanglerIsAGod]

And of course the downside to not changing your password is now that the hashes have been stolen it's only a matter of time until they can log in as you. Since you are never going to change your password 3 years from now your LinkedIn account will still have the same one that was leaked.

Re:The significance of LinkedIn

[Sir_Sri]

Even if you change your password now what does that get you? If they're still unsalted SHA1 any minimally competent man in the middle attack will be able to get the hash, and then your password, as if it was part of this release.

If linkedIn actually has a different security system live and these are all old accounts who haven't changed passwords or the like, well then you have some idea what's going on. But changing your password from one unsalted SHA1 hash not tied to an account to another unsalted SHA1 hash doesn't get you a whole lot.

Re:The significance of LinkedIn

[WuphonsReach]

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.

How many sites do you *really* need to log in to outside of your own personal machine? Memorize those and use some sort of mechanical system for remembering the rest.

This could be as low-tech as a 3x5 index card that you keep tucked away in an envelope at home. Or a folded over scrap of paper in your wallet/purse. Or something as high tech as the various password safes or GPG encrypted text files or just letting the browser remember the password.

Not exactly

[ptrourke]

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

[jellomizer]

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

Re:MaryJune05

[Anonymous Coward]

Phew, close one, my password is MaryJane420.

Client Side Certificates already here....

[Anonymous Coward]

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

Salting isn't very valuable any longer

[Anonymous Coward]

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:Salting isn't very valuable any longer

[happyg]

Salting still helps because it makes rainbow tables useless - you'd have to generate a rainbow table for each salt. Since the salt is used only once (unique per user), you'd have to brute force each password individually.

You are correct that md5 hashes can be generated very, very quickly now, so millions of password combinations can be tried per second, but it effectively multiplies the amount of work an attacker would have to do by the number of users (assuming they try to break every password). Using something like bcrypt (http://en.wikipedia.org/wiki/Bcrypt) which incorporates salt + a hashing algorithm that takes longer to calculate can make cracking passwords *much* more difficult as each password attempt takes more than 0.00000001 seconds, and they have to do it for every user.

Then for bonus points, if you then ALSO use a (long) global salt that you don't store in your db (i.e. in a config file), they won't be able to crack any passwords unless they can also get access to your config files.

Re:Salting isn't very valuable any longer

[Medievalist]

Salting still helps because it makes rainbow tables useless - you'd have to generate a rainbow table for each salt. Since the salt is used only once (unique per user), you'd have to brute force each password individually.

It seems to me that generating huge rainbow tables extremely quickly should be quite doable with a large botnet, because it's inherently a highly parallelizable task.

The raw horsepower advantage of criminal botnets probably makes a lot of the existing password dogma obsolete. Criminals won't necessarily have to pay for their CPU cycles, they can externalize that cost onto Comcast's customers. Legitimate operators have to pay for operating costs.

I think your final point is right on, though - use per user salts, a global salt stored separately, do hashing on the server side, only allow password submission over encrypted channels, and do dictionary checking at password change time, and I think you'll have achieved the current state of the art.

Re:Salting isn't very valuable any longer

[theshowmecanuck]

I'm curious, what methods do people generally use for coming up with a salt?

Also, since you obviously need to be able to retrieve the salt in order to validate a login, where do you store it? In a database along with the hashed concatenated salt+password? (RDBMS, LDAP, doesn't matter in this case, a database is a database is a database... a place to store data)? That is you have the unencrypted salt (so you can retrieve it again) possibly in the same table as the hashed value? Since you can't decrypt a hash I assume you take the password entered by the user, concatenate it with the salt you retrieve from the database and then hash it, and then either store the mangled concatenated pair when storing a new password, or compare the mangled up salt+password to what is stored in the database if someone is trying to log in. Or do you pick some aspect of the account that isn't likely to change and use it as a salt so you don't have to store it, and then hope the hacker doesn't figure out your scheme (or a disgruntled co-worker doesn't spill the algorithmic beans to the world).

I guess if the attacker hasn't been able to get into your database they have to figure out the salt etc. But if they manage to hack your system and get into the database the whole thing is moot.

Enlighten me people!

Re:Salting isn't very valuable any longer

[happyg]

There are different methods to come up with the salt. I typically use a "random" byte array (32 bytes or something). I'm not exactly sure the bcrypt algorithm's salt generator. Some people use the user's id (though that's not very useful if it's just a Long. Could work if it's a guid). It doesn't really have to be random so much as unique, and enough bytes that it's long enough make a rainbow table useless (i.e. if you use 2 bytes of salt, and a user has a 6 character long password, a rainbow table that has all passwords that are 8 bytes long will still contain the password+salt combination).

You store the salt in plain view in the database, along with the user's password. You can even store the salt in same field as the hashed password like so: $hash$salt (you can extract the hash because it's a known length, same with the salt, or you can use an actual separator between the two). The salt isn't intended to be secret. It's purpose is to thwart someone who has a big table of hashes -> passwords, guaranteeing your passwords won't be in that list. Likewise, if two people have the same password, they'll have different salts, so their hashes will be different. This means if they figure out one hash -> password, it won't tell them anything about any other passwords.

Re:Salting isn't very valuable any longer

[happyg]

You have a good point regarding using botnets to break the salted passwords, since as you say it's highly parallelizable. At the same time, why make it easy for them? If they have to rent time on a botnet to break the passwords (or spin up a bunch of gpu instances in ec2), so much the better. Especially if you use a slow hash algorithm - if it takes .01 second per hash attempt, and you have a million users with unique salts, they'd have to spend 0.01 * 1,000,000 seconds per password attempt per user, which is 10,000 seconds, or cpu 2.7 hours. That means to test the letter "a" on every user, they'd spend 2.7 cpu hours. Even with a massive botnet I imagine that would get prohibitively expensive really quick. If they had 10 million machines in a botnet, it would take 10,000/1,000,000 = 0.01 real seconds per password attempt per user. A standard dictionary might have something like 40 million entries (http://www.openwall.com/wordlists/). That translates to 400,000 seconds to try the entire dictionary, or 111 real hours**. Doable, but hopefully expensive (I'm not sure the going hourly rate of a 10 million machine botnet). Feel free to check my math, by the way.

**Of course users usually pick bad passwords, and the common ones could be checked first, so it's unlikely they'd have to run the entire dictionary to crack most of the passwords.

Re:Salting isn't very valuable any longer

[theshowmecanuck]

When someone is trying to get into the system by brute force, are they not just throwing a ton of passwords (even via rainbow tables) at the established authentication system?

It seems to me that the client would have to know the salt ahead of time (i.e. some time well before they even try to log in) to create a secure salted password to send to the login service. And wouldn't this then be kind like a pseudo public key encryption? If the client doesn't have the salt then they are just sending a plain password which gets salted/concatenated once it reaches the server (you would need to do this from what you say so that you can compare the provided password to what is stored in the DB). So then the hacker only needs to brute force it.

And if you provide them the salt during the login process (i.e. not ahead of time) they still only need to figure out or throw a bunch the plain passwords at the server... brute force it.

And if they aren't trying to brute force things through the established app API, then presumably they are attacking say the database directly. And then they can get your data directly.

Do you know any good documents online that explain how this works? Salting that is. I'm still not sure how it really helps. It sounds good in theory. But I guess until I find something that explains it well, I still don't see how to implement it effectively. I have looked, but other than a bunch of posts telling people to concatenate a salt with the password, there isn't much out there as far as I can tell.

Re:Salting isn't very valuable any longer

[happyg]

The salt's 100% server side - the client never knows about it, or even if his/her password is being salted and hashed, or stored in plaintext (unless they're able to send you your password - then you know it's stored in plaintext).

When someone is trying to get into the system by brute force, are they not just throwing a ton of passwords (even via rainbow tables) at the established authentication system?

It depends how they're trying to break into the system, but typically no. If they're trying to send lots of login attempts against the the established authentication system, that's something you as a server admin can detect. To protect against it, you can rate limit requests from that ip address. For example: the first 3 password attempts within n-seconds execute as fast as your servers can handle, but on every subsequent attempt you delay the response by a quarter second, then a half second, then a full second, then two seconds, etc. If they try too often, you can ban the ip address**, and possibly have the server send out a message to the admins.

It seems to me that the client would have to know the salt ahead of time (i.e. some time well before they even try to log in) to create a secure salted password to send to the login service. And wouldn't this then be kind like a pseudo public key encryption? If the client doesn't have the salt then they are just sending a plain password which gets salted/concatenated once it reaches the server (you would need to do this from what you say so that you can compare the provided password to what is stored in the DB). So then the hacker only needs to brute force it.

If you were to have the client send up the salt with their password (or hash it themselves), you'd be correct. But the server's the one who generates and stores the password, and the client never sees it or knows about it.

And if you provide them the salt during the login process (i.e. not ahead of time) they still only need to figure out or throw a bunch the plain passwords at the server... brute force it.

True, but you can detect when something is sending thousands or more password attempts at a server and block it.

And if they aren't trying to brute force things through the established app API, then presumably they are attacking say the database directly. And then they can get your data directly.

Exactly; almost all these comments assume the attackers have gained access to your database. The idea is that even if they can get your data directly, they still won't be able to figure out a user's login credentials. Depending on what your site does, that may or may not be a big deal for your users. As a user, if they got a copy of my profile on linkedin, I wouldn't care too much. It'd be bad, sure, but not the end of the world. If they could figure out my password and log in to the site, and start posting as me, that's a problem. Same thing with banking credentials (knowing my balance vs. being able to change my balance), and most places where I need a password.

The other problem is password reuse. Many users reuse their passwords on multiple sites. That means if you can crack a million user's linkedin accounts, you now have their email + passwords. If you then try logging into gmail with those same emails + passwords, you might get in to 100,000 of them. And then you can try their other accounts (say, banking) and even if those fail, you can try to do a password reset, and if you own their email address you can usually "confirm" the reset and set their password to whatever you want.

Do you know any good documents online that explain how this works? Salting that is. I'm still not sure how it really helps. It sounds good in theory. But I guess until I find something that explains it well, I still don't see how to implement it effectively. I have looked, but other than a bunch of posts telling people to concatenate a salt

Re:Salting isn't very valuable any longer

[WuphonsReach]

Go look at how "crypt" works.

$ man crypt

Passwords get stored as "$id$salt$hash". The "id" bit lets you identify what hash method you're using and can be any sort of system that lets you keep track of what hash method a particular account is using to store the password hash. The "salt" bit is the random, per-user, salt (crypt allows up to 96 bits worth of salt, as it allows 16 characters chosen from a set of 64 possibles). The "hash" is the output of (salt + password -> hash algorithm).

whats so horrid about it

[KingBenny]

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

[KingBenny]

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

[Megane]

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

[cluedweasel]

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

[Anonymous Coward]

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

[cluedweasel]

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

Mental image

[ThatsNotPudding]

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.

seems the md5crypt guy just posted to bugtraq

[spottedkangaroo]

Don't use his md5crypt and think you did anything useful he says. http://phk.freebsd.dk/sagas/md5crypt_eol.html

Re:Do they understand how hashes work?

[Anonymous Coward]

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

What difference does it make?

[WaffleMonster]

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?

[zzsmirkzz]

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.

Re:What difference does it make?

[silas_moeckel]

Your not really adding security by splitting it up, a well protected server that only stored uuid and salted hashes would do the same.

Re:What difference does it make?

[zzsmirkzz]

I was implying using a different/random salt value for every individual password. It is my understanding that it would be impossible to brute-force a password for a salted hash whose salt is not known. You can get the original value passed to the hash function but not the actual password. You would then have to try and deduce the salt. If this is true then separating the hash from the salt does add security.

Re:What difference does it make?

[shutdown -p now]

These passwords can still be brute force at todays mega ridiculous n core, GPU accelerated rates at extremely low cost.

Go ahead, try bruteforcing high-cost bcrypt.

Re:What difference does it make?

[Anonymous Coward]

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

Sorry, but this is just silly. Salting takes you from needing trivial effort to crack a sizable percentage of a password pool (using rainbow tables) to needing substantial brute-force effort just to crack a single password. It takes you from having obvious targets for additional brute-force attack (password hash collisions) to having none.

If you're an evil hacker and someone gives you a corpus of unsalted password hashes that's an instant goldmine in compromised accounts. If someone gives you a corpus of salted password hashes? Who's going to spend the time brute-forcing each individual password? You're better off finding an easier target.

So yeah, there's a freaking HUGE difference between a database of millions of salted passwords being compromised and a database of millions of unsalted ones.

Re:What difference does it make?

[blueg3]

Actually, it does a few things:
* It makes rainbow tables ineffective.
* It prevents identification and lookup of common passwords (e.g., by pasting the SHA-1 hash into Google)
* It make cracking a list of N passwords a factor of N harder.

The last is fairly important for large database leaks. A single password is no harder to compute if you add salt, but if you're brute-force cracking against the entire password list (which is what you want to do), it's a factor of a million slower because you can't just compute the SHA-1 for a single test password and compare it against every entry in the database; you need to compute the SHA-1 for each (password, user) combination. That's a substantial slowdown, and cracking against a large leaked database is a much more common way of passwords being exposed than a concerned cracking effort against a single account.

Re:What difference does it make?

[Anonymous Coward]

I was implying using a different/random salt value for every individual password. It is my understanding that it would be impossible to brute-force a password for a salted hash whose salt is not known. You can get the original value passed to the hash function but not the actual password. You would then have to try and deduce the salt. If this is true then separating the hash from the salt does add security.

Having a "secret salt" would do rather little. In order for anyone to log on, continuous access to both the database of salts and the database of hashed password+salt would be required by the web server so it can check whether a given password is correct. Anyone who has compromised the web server would have both. You may as well put them in the same place, as every system I have seen does.

The real benefit of salts is simply to make pre-computed dictionary attacks unfeasible (assuming a salt of reasonable length and random distribution). For example, with a 32 bit salt you would need to pre-compute over four billion versions of your 'common password dictionary'. With longer salts it gets exponentially better, and the additional storage space per user is trivial.

Re:What difference does it make?

[Sir_Sri]

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.

Re:What difference does it make?

[silas_moeckel]

A different random salt per hash is expected (otherwise it's nearly useless). In the good better best of security you have salted hashes stored along with everything else, a box that gets sent the password and uuid (or whatever unique identifier is used), and a box that is sent a uuid and random string to hash with the password and the client does that same. Splitting up the hash parts onto two separate servers does very little as they are both involved and one have to send it's part of the hash to the other to work it out, so one of them at some point with halves the two halves anyways and you can game the system to get it to have the ones your interested in at that time.

Honestly web sites need to get past mucking with passwords, there are numerous better ways to authenticate, that do not require individual web sites to have any sort of password on file. This makes otp, keyfobs, smartcards etc much more palatable and does not require anything extra on the web site. Sites need to learn that handling passwords is a liability they should try and avoid. Users can pick whoever they want to handle there identity including themselves if they are technically inclined. Sure it's not perfect and can still be gamed but little in security is perfect.

Re:What difference does it make?

[WaffleMonster]

Who's going to spend the time brute-forcing each individual password? You're better off finding an easier target.

So yeah, there's a freaking HUGE difference between a database of millions of salted passwords being compromised and a database of millions of unsalted ones.

Your making some assumptions:

1. Cracking a single password has no value.
2. The value of every user is equal.
3. Out of a space of millions just running well known/shit passwords at a cost of 1min/core would not easily yield many thousands of passwords.

Compromising a site like Linkedin may pose little reward to an attacker however there may be huge payouts if the same password can be used to gain access to corporate or financial resources.

If the only threat was spam/phishing I would tend to agree with your assessment. In my view it is dangerous and unwarranted to make this leap.

Re:What difference does it make?

[WaffleMonster]

it's a factor of a million slower because you can't just compute the SHA-1 for a single test password
That's a substantial slowdown,

I had already point this out myself. See my origional comment "Salting only protects you from precomuted "rainbow" brute force methods".

Whether salted passwords are worth compromising is a value proposition for the ATTACKER to decide. Maybe they have a botnet at their disposal sitting idle which can be tasked with the cracking initiative? I simply claim if one password is worth trying to brute force then a million passwords will yield a much larger ROI.

If your password cracker follows an algorithm where it exhausts the entire keyspace on each password sequentially rather than scanning for high probability passwords across the entire space first then it might be time to upgrade.

You can still yield countless thousands of passwords easily with minimal effort with salted passwords. To be successfull you might not need to crack them all or even a majority.

Re:What difference does it make?

[WaffleMonster]

Go ahead, try bruteforcing high-cost bcrypt.

Password amplification schemes are an interesting idea they seem to afford practical protection against offline attack for all but the most easily guessed of passwords.

Re:What difference does it make?

[WaffleMonster]

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

I agree.. In fact it is much much better than this as a rainbow table need only be computed once and used eternally for all subsequent cracking campaigns against passwords using the same algorithm. Storage is not free however.

. 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

I would caution against simple extrapolation. Password guessing is an activity with a long tail.

You will quickly recover many low hanging fruits initially. Only later will you see fewer and fewer returns as the amount of computation required to recover more difficult to guess passwords approaches unprofitable.

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

A static assumption of attacker resources seems unlikely to occur in the real world. For any of us know chunks could have been sold off to friends or unfreindly governments each with their own separate compute resources. It could have been distributed to a botnet with hundreds of thousands of nodes or attacked by custom asics.

It also depends on the market value of a successfully compromised account. It may be out of the 6 million only a few thousand accounts are actually worth anything or worth much more than others.

I'm not so sure safety in numbers is a safe bet for everyone... I don't see how it is possible for a potential victim to know what their odds are in the first place as this would require them to know who has the passwords, what recovery resources they have and what they plan on doing with them.

Re:What difference does it make?

[Sir_Sri]

Of course to all of your points.

I was being illustrative of what salting does not a technical analysis of compromising passwords.

it was sort of obviously contrived, as passwords are never going to take exactly 525.95 seconds, and I'm not going to live exactly 50 years (now minus 2 days).

You might not recover low hanging fruits quickly with salting. It depends on the salting, if it just adds a couple of alphanumeric characters it's not adding a great deal, but a good salting algorithm could take a trivial password 1234 and turn it into #1_2_June*10_sqrt((to 8 digits)asciicodeof(3))@accountname4.

Re:What difference does it make?

[blueg3]

I had already point this out myself.

No, you said, "[s]alting only protects you from precom[p]uted "rainbow" brute force methods". I agreed that this was one thing that they protect you against, but it is not the only thing. I listed three things, one of which was rainbow tables.

The "factor of a million slowdown" is referring to the third item I listed. If you have a list of N possible passwords and K password hashes, the total cost of testing the passwords is O(N) for unsalted passwords and O(K * N) for salted passwords. This is because when you compute the hash for one of the passwords, you must use one of the salts. So, you have to compute K different hashes, one for each salt, whenever you test a single password. This is not the same as protecting you against rainbow tables, which are effective regardless of the number K.

Re:What difference does it make?

[WaffleMonster]

The "factor of a million slowdown" is referring to the third item I listed. If you have a list of N possible passwords and K password hashes, the total cost of testing the passwords is O(N) for unsalted passwords and O(K * N) for salted passwords. This is because when you compute the hash for one of the passwords, you must use one of the salts. So, you have to compute K different hashes, one for each salt, whenever you test a single password. This is not the same as protecting you against rainbow tables, which are effective regardless of the number K.

I don't see any difference between a "rainbow table" and taking the fruit of a hash operation and searching the space of K hashes for duplicates. It is logically the same operation although technically there are likely to be differences in implementation. The only distinction is in the weeds of who computed what when.

It is not really O(N) because searching K space may be cheap but it is not free the same way searching a precomputed table is not free.

When I say rainbow tables don't work on salts it implies they also don't work when you carry out the same logical operation and call it something else.

Re:What difference does it make?

[blueg3]

They're not the same operation at all. A rainbow table isn't just some precomputed lookup table. It enables you to do a reasonably space-efficient partial precomputation of hashes, giving you a factor of X speedup in reversing a hash.

Notably, the speedup a rainbow table provides is the same regardless of whether you're cracking one password or N.

The slowdown due to users having different salts is always a factor of K, where K is the number of users.

It is not really O(N) because searching K space may be cheap but it is not free

It's not free, but (a) an efficient implementation of searching the space K is constant-time and (b) every other password-cracking operation is so much cheaper than SHA-1 that they might as well be free. So yes, it's even technically O(N) since the K-space search is constant in K.

Passwords? We don't need no stinking passwords!

[Anonymous Coward]

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?

So what?

[pubwvj]

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?

[Kyrene]

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.

Re:So what?

[asdf7890]

It is a bigger deal than that. It isn't just if someone on the same service (or another service with a leak) happens to have the same password (so without a user-local salt portion have the same hash) - rainbow tables for the common hashes (MD5, SHA1) exist for a large portion of passwords. If your password is simple enough to be in one of those tables and it is stored hashed but without any salt, then it can be guessed very easily using the hash and a table. http://www.freerainbowtables.com/tables/ is the first hit when I search for them in Google, there may well be better/bigger/what-ever out there.

You are still (better) protected if you have a "secure enough" password, and have different passwords for each account, but there are many people who don't do either of these things so many are potentially at risk. "Why should I care?" I hear you ask: well if the fool that had bad passwords discovered that way had access to some power or public resource and was further daft enough to use similar (it doesn't have to be the same) passwords for said resource/access, then a leak of unsalted passwords could very much affect you or people you care about even if you purge from your life anyone who ever dares to use a simple password.

Re:So what?

[Johann Lau]

"Why should I care?" I hear you ask: well if the fool that had bad passwords discovered that way had access to some power or public resource and was further daft enough to use similar (it doesn't have to be the same) passwords for said resource/access, then a leak of unsalted passwords could very much affect you or people you care about even if you purge from your life anyone who ever dares to use a simple password.

Quoted just for the sheer truth of it.

CANCELED LINKEDIN

[Anonymous Coward]

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

Re:Do they understand how hashes work?

[Anonymous Coward]

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.

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

[Anonymous Coward]

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.

Resume Posted to Linkedin

[wideBlueSkies]

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.

Premium Users

[asdf7890]

I suggest all premium users, who have paid for the service in some way or another, request some for of discount for a while. Any service that that effectively holds the keys to part of your public identity doesn't understand and implement basic credentials security (especially after the few high-profile cases that have hit in the few years prior to this incident) is simply not fit for purpose.

tempting fate

[Anonymous Coward]

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.

I think a lot of people are thinking one thing, but saying another (inaccurately).

It's not so much a cyclist deserves getting hit by a car when they blow through a intersection, but they're asking for it. It's not so much that Bishop Desmond Tutu deserves to get zapped by lightening, but he's asking for it he places golf during a thunderstorm on an wide open golf course.

A think lot of people say "deserve it" when they really mean "ask for it". If you're going to 'tempt fate', then don't be surprised if the dice roll against you at some point.

Salt their hide

[Anonymous Coward]

Maybe something like

5a177h3e1rh1D3

would still be convenient to remember while being tougher to crack?

Re:Do they understand how hashes work?

[Anonymous Coward]

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

Fail. Hashes are a many-to-one mapping, not one-to-many.

I have a question, though...

[bmo]

The file going around is simply a pile of hashes, no logins. Did the crackers get both? Or did they just get the hashes?

Because the hashes may as well be piles of random data if you can't pair them with a login.

I have not heard a peep about the logins themselves. Are we just assuming they were taken?

--
BMO

Re:I have a question, though...

[bill_mcgonigle]

I have not heard a peep about the logins themselves. Are we just assuming they were taken?

Yep - plan for the worst, hope for the best.

"Password" Manager

[bazald]

It's called a password manager. KeePass is a nice one. There are many others. How many passwords are so important to you that must internalize all of them? For me, the answer is "very few". Never reuse. Never recycle.

Still, you're right that passwords are unideal--a PGP-like solution would be better. Even done poorly, all they could leak would be the information that you have an account. But if you stored a different PGP-key for each site in Keepass, then they couldn't even do that.

Re:Do they understand how hashes work?

[omarius]

Huh?

sha1sum blah = 5bf1fd927dfb8679496a2e6cf00cbe50c1c87145
sha1sum 5bf1fd927dfb8679496a2e6cf00cbe50c1c87145 = 9dbc5291ce0269baafbf68a6346b5510a1b30860
sha1sum 9dbc5291ce0269baafbf68a6346b5510a1b30860 = caa4e37211fda75d91b9bf3231f9fbeb434d56e8
[...]

Re:MaryJune05

[Anonymous Coward]

No more dances for you!

So how do we fix this?

[geekfarmer]

Obviously, linkedin is learning fast from the publicity here, but that doesn't stop other companies from sending emails with your password if you click "forgot password". (*cough*T-Mobile*cough*) I deny that proper password security is either hard or expensive. What we really need is a good way to shame companies into doing it right. Preferably one that doesn't involve leaking a few million passwords.

Re:Do they understand how hashes work?

[Anonymous Coward]

Um, no, it's many-to-one; a hash is a function - meaning it is deterministic - whose codomain is smaller than the domain. For any string s, h(s) = h(s). If you hash the same password without a salt using the same hash function (assuming a null key, which is usually used with hash functions with this application), you will always get the same hash.

Using a key doesn't help, because once you have the key, you only have to calculate one rainbow table. It's better than using the precompiled rainbow tables for null keys, but not much.

Using a salt, on the other hand, forces you to build a rainbow table for each salt value.

Lession Learned

[Anonymous Coward]

I learned about this a few years ago when my application under went a code review by Wells Fargo. However, the fix wasn't that difficult to implement. Since un-salted MD5 can be "easily" cracked, it was possible to write an application which decrypted the passwords in the database and re-encrypted them with the new salt. Luckily the database wasn't too large at the time so the application finished in a few hours.

Re:Do they understand how hashes work?

[Anonymous Coward]

What he is saying is that "blah" isn't the ONLY string that yields a hash of "5bf1fd927dfb8679496a2e6cf00cbe50c1c87145".

However, finding any of the (infinitely many) strings that do is... difficult.

Long random salt, PBKDF2 with n00,000+ iterations.

[Anonymous Coward]

Basic password security these days:

When users select a password, check whatever the user submitted against a set of common password dictionaries - ideally, apply some rules to it (733t speak translation, add numbers or symbols to the beginning or end, capitalization games, etc.). This should help prevent P@$$w0rd (8 characters, upper case, lower case, numbers, symbols - it must be a great password!)

Use a Long, cryptographically random salt. This makes attacks against sets of password hashes more expensive.

Use a known PBKDF2 implementation (http://www.ietf.org/rfc/rfc2898.txt); perhaps BouncyCastle or Microsoft, with at least a couple hundred thousand iterations. This makes attacks against even one password hash much more expensive.

If your PBKDF2 implementation allows it, use SHA512 (best) or SHA256 as the hash algorithm. This also makes attacks against even one password hash more expensive.

Re:Do they understand how hashes work?

[Anonymous Coward]

The parent AC probably meant if you hash blah 50 times with the same algorithm you always get the same output (ie, the algorithm is deterministic, not random).

Salts are useless with fast hashes

[Anonymous Coward]

The attack on MD5 and SHA1 passwords is brute force, and it's quite tractable on commodity GPU hardware. This is why you use a proper KDF like bcrypt.

Re:MaryJune05

[Anonymous Coward]

It's true! I'm now posting from your AC account!

Couldn't this just be a hoax?

[Xenna]

Think about it. 6 million unsalted password hashes without matching use data. If this is real password data, how big is the chance that someone would find their password in there?

Perhaps as big as the chance that you get a Google hit when you search for your password?

AFAIK all we have is:
- Someone posting a list claiming it's from LinkedIn
- Some people confirming that the hash of their LinkedIn password is on that list

That doesn't really prove anything, right?
- People tend to pick similar passwords
- People use the same password on different sites

I read this in some blog, but I already had my doubts then.

Re:Do they understand how hashes work?

[jellomizer]

I guess you don't use terminal type 3270 too often. Control E is often configured to clear your field from the cursor to the end. So your password would be saved as what you typed minus the Ctrl-E... Unless you intentionally go back a few characters and do the ctrl-e last.

Back in the olden days of DOS my password often had Alt-219 atl-176 alt-177 and alt-178

Drives me up the wall, so sent them a reminder

[Anonymous Coward]

Really drives me nuts, such a company and such a rookie oops. Could not bring this to words in a complaint, so I sent them a bag of salt. Substantial amount, 25 lb, to be there as a reminder. Arrives by EOB Thursday.