Unless I missed it, the article didn't specify which algorithm LivingSocial was using (LS probably didn't say, which likely means it's MD5 or part of the SHA family). Hopefully it's something along the lines of PBKDF2 with a very high work factor... if it was, then even a moderately crappy password could take a few days to crack, and a good password (not great) months to years.

On the other hand, if it was MD5, crackers have probably cracked many millions of them already (assuming LivingSocial discovered the break in immediately after it occurred), and well on their way to the same 90+% breakage that occurred for LinkedIn.

This is all the more reason to use a Password Manager that can generate completely random, long passwords for each individual site you use (very few people can/are willing to remember dozens upon dozens of unique passwords... and using a pattern system to help you remember is a BAD idea). Even with cloud syncing enabled all the popular ones would be extremely hard to crack, thanks to choosing good KDFs with relatively high work factors (one secure password is much easier to remember than a dozen mediocre ones).

As in much, much higher penalties for both the hacker AND the website that gets hacked.

For the hackers, longer prison sentences, wider range of what is considered criminal activity. If they ramped this up to say, a possible 20+ year prison term, with no exceptions for age (all tried as adults), you'd probably see a decent drop in this. As it is, 3-5 years, or just probation if you are underage, obviously is no deterrent at all.

For the website, more safe practice requirements and regulation with fines and/or other penalties for failure to use best practices. Not saying LivingSocial wasn't using best practices, but there have been far too many that haven't (cough, Twitter, Sony, TJ Maxx, cough).

But aside from the time investment, salting in no way makes cracking more difficult."

In case of hashed password breaches, time (and the associated computing power/energy) is the only thing that ever matters.

Yeah, this is an odd thing for the article to say. The only difficulty surrounding cracking hashes *is* time, so if you increase the time investment, you do make cracking more difficult. Salting especially, since it prevents rainbow table attacks, and means each password has to be attacked individually. That in turn means only the easy-to-break (8-10 character and/or dictionary based) passwords are likely to be cracked at all. I doubt they'll invest the time to brute force every single password, although of course if your password is "12345" you're still screwed.

One thing I don't understand. How do they know what algorithm was used?

I can understand if encryption was done purely locally and then sent to the servers, because they could use various techniques to read the memory states and figure out from there. But why stop there? Why not have, say, the local machine run it through a few rounds of various methods, send the encrypted hash to the server for validation, which then runs it through another few rounds (few, in context, meaning hundreds? thousands? whatever is appropriate). I mean, even if you used crappy algorithms but used them in a long, complex sequence, they wouldn't be able to be guessed unless someone knew exactly the sequence, right? Even if the person who extracted the hash list had an account and thus had one password where they knew the input and output, they still would have to spend a lot of time basically running every possible combination of every common method for lots of potential iterations. What if you took it one step further and the actual hash that gets sent to the server in some way influences the pattern of hashes the server runs it through before storing? Even when they finally managed to break one, the same pattern of hashes wouldn't actually break a 2nd one, they'd have to start over from square 1. Think of it like salt, on crack.

Example: The hash sent to the server was AkdiT, and the server sees that hash and uses the first position 'A' to say "okay, run a Sha1," then the second position of 'k' means "Sha256." But if the next hash that comes in is kAdiT, then it runs Sha256 THEN Sha1. And you'd have to figure that out for each and every password, at least until you cracked enough to find the patterns used.

This is all the more reason to use a Password Manager that can generate completely random, long passwords for each individual site you use (very few people can/are willing to remember dozens upon dozens of unique passwords... and using a pattern system to help you remember is a BAD idea). Even with cloud syncing enabled all the popular ones would be extremely hard to crack, thanks to choosing good KDFs with relatively high work factors (one secure password is much easier to remember than a dozen mediocre ones).

Heh...I often wish I could switch full-time to a password manager, which generates and stores complex passwords. On my desktop systems, I use both Firefox & Chrome for my web-browsing, and both happily accept the LastPass Plugin.

The *only* thing that prevents me from going that route full-time is the fact there is no Last Pass plugin for Chrome on Android. (Well..there are no plugins on Android Chrome AFAIK) I realize that the Dolphin Browser has support for Last Pass, however, I've never really liked that browser.

A simple regulation could help with this, nothing drastic but something along the line of how credit cards and PCI.

PCI dictates minimum security standards as well as what you can actually store. For example, you can only store embossed credit card data and depending on the network access it must be encrypted.

These are subject to audit regularly as well.

Something simple like this, but for account information and personal information would help prevent some of the availability of data if it stipulated better encryption methods as well as was updated as technology advanced.

But aside from the time investment, salting in no way makes cracking more difficult."

In case of hashed password breaches, time (and the associated computing power/energy) is the only thing that ever matters.

Yeah, this is an odd thing for the article to say. The only difficulty surrounding cracking hashes *is* time, so if you increase the time investment, you do make cracking more difficult. Salting especially, since it prevents rainbow table attacks, and means each password has to be attacked individually. That in turn means only the easy-to-break (8-10 character and/or dictionary based) passwords are likely to be cracked at all. I doubt they'll invest the time to brute force every single password, although of course if your password is "12345" you're still screwed.

Maybe I'm missing something, but shouldn't the salt prevent easy cracking of "12345" because it's really "12345 + salt" = unique hash? Assuming LivingSocial properly implemented the salt, then dictionary attacks should be worthless (which, according to prior Ars articles, it the primary method for cracking), and bruteforce is hardly going to be worth it (as others pointed out, you can crack anything given enough time).

But aside from the time investment, salting in no way makes cracking more difficult."

In case of hashed password breaches, time (and the associated computing power/energy) is the only thing that ever matters.

Yeah, this is an odd thing for the article to say. The only difficulty surrounding cracking hashes *is* time, so if you increase the time investment, you do make cracking more difficult. Salting especially, since it prevents rainbow table attacks, and means each password has to be attacked individually. That in turn means only the easy-to-break (8-10 character and/or dictionary based) passwords are likely to be cracked at all. I doubt they'll invest the time to brute force every single password, although of course if your password is "12345" you're still screwed.

Based on what we've learned from previous password breaches, a statistically significant percentage of LivingSocial users likely chose extremely weak passwords that we can presume are already broken. Hence, it's misleading to say that salting makes these passwords hard to decode. I don't think it's odd for an article to point this out, given the lack of clarity on this point from LivingSocial.

But aside from the time investment, salting in no way makes cracking more difficult."

In case of hashed password breaches, time (and the associated computing power/energy) is the only thing that ever matters.

Yeah, this is an odd thing for the article to say. The only difficulty surrounding cracking hashes *is* time, so if you increase the time investment, you do make cracking more difficult. Salting especially, since it prevents rainbow table attacks, and means each password has to be attacked individually. That in turn means only the easy-to-break (8-10 character and/or dictionary based) passwords are likely to be cracked at all. I doubt they'll invest the time to brute force every single password, although of course if your password is "12345" you're still screwed.

Maybe I'm missing something, but shouldn't the salt prevent easy cracking of "12345" because it's really "12345 + salt" = unique hash? Assuming LivingSocial properly implemented the salt, then dictionary attacks should be worthless (which, according to prior Ars articles, it the primary method for cracking), and bruteforce is hardly going to be worth it (as others pointed out, you can crack anything given enough time).

No, salting in no way prevents dictionary attacks. It just makes dictionary attacks run slower than they would if salting wasn't applied.

Passwords should be randomly generated by a password-manager, contain a minimum length of 11 characters, and include numbers, letters, and symbols. They should also be unique to each site.

As an aside, I've run across plenty of sites that don't accept anything but numbers and letters. Some of the ones that don't will accept a password with symbols, giving you the illusion that it was OK, but try logging in with that password and it never works.

The problem is that password encryption or storage security measures should not be viewed as some kind of fortified bulwark that actively keeps out all but the most determined attackers.

A password breach should be viewed as a raging inferno in a building and any security measures in place are analogous to fire-resistant building materials and sprinklers in a warehouse full of flammable goods - they only buy time for the occupants to escape, they don't make it safe to remain inside the burning building.

But aside from the time investment, salting in no way makes cracking more difficult."

In case of hashed password breaches, time (and the associated computing power/energy) is the only thing that ever matters.

Yeah, this is an odd thing for the article to say. The only difficulty surrounding cracking hashes *is* time, so if you increase the time investment, you do make cracking more difficult. Salting especially, since it prevents rainbow table attacks, and means each password has to be attacked individually. That in turn means only the easy-to-break (8-10 character and/or dictionary based) passwords are likely to be cracked at all. I doubt they'll invest the time to brute force every single password, although of course if your password is "12345" you're still screwed.

Maybe I'm missing something, but shouldn't the salt prevent easy cracking of "12345" because it's really "12345 + salt" = unique hash? Assuming LivingSocial properly implemented the salt, then dictionary attacks should be worthless (which, according to prior Ars articles, it the primary method for cracking), and bruteforce is hardly going to be worth it (as others pointed out, you can crack anything given enough time).

Dictionary attacks have nothing to do with salts. Dictionary attacks, as the name explicitly says, are attacks that leverage a dictionary (you know, of "words"?) to try to guess the passwords.

Salts prevent two things: They prevent using precomputed tables of hashes (such as rainbow tables) to attack a stolen set of hashes (which only get you so far), and they prevent attackers from hashing a guess once and comparing it against 50 million passwords (in this case, to crack all users with the password '12345' they'd have to hash '12345' 50 million times, instead of 1 time if you didn't salt!).

Hackers also don't do a real 'bruteforce' attack, at least for passwords beyond a certain (very short) length. Typically around 8 characters (+- 2 or so, depending on the algorithm). Instead, they use various sorts of attacks that they to guess your password (not just do an exhaustive search of all possible ones). They take a dictionary (which will include things like english words, phrases, previously-cracked passwords, names, etc), and test those. They'll also take each of those items in the dictionary, and mutate them based off various rules, such as '<lastname>[0-9][0-9][0-9][0-9]', because a lot of people use a password that's a last name and a year. Other rules are things like leet-speak versions of the passwords, and about a bajillion others. This is how they can crack so many, even ones they'd never be able to crack via a true brute force attack, even if the site was just using MD5.

But aside from the time investment, salting in no way makes cracking more difficult."

In case of hashed password breaches, time (and the associated computing power/energy) is the only thing that ever matters.

Yeah, this is an odd thing for the article to say. The only difficulty surrounding cracking hashes *is* time, so if you increase the time investment, you do make cracking more difficult. Salting especially, since it prevents rainbow table attacks, and means each password has to be attacked individually. That in turn means only the easy-to-break (8-10 character and/or dictionary based) passwords are likely to be cracked at all. I doubt they'll invest the time to brute force every single password, although of course if your password is "12345" you're still screwed.

Maybe I'm missing something, but shouldn't the salt prevent easy cracking of "12345" because it's really "12345 + salt" = unique hash? Assuming LivingSocial properly implemented the salt, then dictionary attacks should be worthless (which, according to prior Ars articles, it the primary method for cracking), and bruteforce is hardly going to be worth it (as others pointed out, you can crack anything given enough time).

Dictionary attacks have nothing to do with salts. Dictionary attacks, as the name explicitly says, are attacks that leverage a dictionary (you know, of "words"?) to try to guess the passwords.

Salts prevent two things: They prevent using precomputed tables of hashes (such as rainbow tables) to attack a stolen set of hashes (which only get you so far), and they prevent attackers from hashing a guess once and comparing it against 50 million passwords (in this case, to crack all users with the password '12345' they'd have to hash '12345' 50 million times, instead of 1 time if you didn't salt!).

Hackers also don't do a real 'bruteforce' attack, at least for passwords beyond a certain (very short) length. Typically around 8 characters (+- 2 or so, depending on the algorithm). Instead, they use various sorts of attacks that they to guess your password (not just do an exhaustive search of all possible ones). They take a dictionary (which will include things like english words, phrases, previously-cracked passwords, names, etc), and test those. They'll also take each of those items in the dictionary, and mutate them based off various rules, such as '<lastname>[0-9][0-9][0-9][0-9]', because a lot of people use a password that's a last name and a year. Other rules are things like leet-speak versions of the passwords, and about a bajillion others. This is how they can crack so many, even ones they'd never be able to crack via a true brute force attack, even if the site was just using MD5.

And of course, they don't care about cracking 100% of the passwords - they're perfectly content to grab the 80% that's easy to hit via dictionary (+rules) attacks.

Salts prevent two things: They prevent using precomputed tables of hashes (such as rainbow tables) to attack a stolen set of hashes (which only get you so far), and they prevent attackers from hashing a guess once and comparing it against 50 million passwords (in this case, to crack all users with the password '12345' they'd have to hash '12345' 50 million times, instead of 1 time if you didn't salt!).

Of course, we're all assuming that they used unique salts for each password. Given that they're using SHA1, I think that may be giving them a bit too much credit.

They've already got the password lists from Linkdin, WorldofWarcraft, and several other sets of million+ users' passwords. And since most of the logins now use your email address as half your login, they'll try your login at all the other sites they think you might access. I'd made the mistake of letting my browser remember the password to a waste of time social networking account. I didn't realize it was the same as the site I'd been informed had lost their password database.. so didn't change it until after the waste of time social networking system informed me my account was being logged into from a different country. Was I on vacation in China?

In one of the recent articles here about password cracking on Ars - I saw a definition of how I constructed my password.

There is NO such thing as safety online. It's always hackable. Always. I wish business didn't think with their monetary sense instead of their heads, but they do. And that is because those millions of ADD type people who are unwilling to have anything but the instant gratification which online shopping provides, will never listen. Enjoy the consequences everyone. And yes, I shop online too. In a very limited way. Stil, I have had my credit card number stolen twice already. And NO, I don't go to questionable download sites to steal music or videos. One was just laziness on my part. Never click on a 'yes' box, and I got in a hurry and did, so that was utterly my oops.

This is all the more reason to use a Password Manager that can generate completely random, long passwords for each individual site you use (very few people can/are willing to remember dozens upon dozens of unique passwords... and using a pattern system to help you remember is a BAD idea). Even with cloud syncing enabled all the popular ones would be extremely hard to crack, thanks to choosing good KDFs with relatively high work factors (one secure password is much easier to remember than a dozen mediocre ones).

Heh...I often wish I could switch full-time to a password manager, which generates and stores complex passwords. On my desktop systems, I use both Firefox & Chrome for my web-browsing, and both happily accept the LastPass Plugin.

The *only* thing that prevents me from going that route full-time is the fact there is no Last Pass plugin for Chrome on Android. (Well..there are no plugins on Android Chrome AFAIK) I realize that the Dolphin Browser has support for Last Pass, however, I've never really liked that browser.

There is an android app, which you can just switch to and copy the password to your clipboard, or add "copy notifications" which put an entry in your notification bar to copy either your username or password to the clipboard when you click it. I use it all the time.

People certainly go out of their way to simplfy things for crackers.I wonder what percentage of people who re-use passwords also re-use their "john@gmail.com" address instead of say, a personal domain with good aliases.

Password advice is one of those black arts since nobody ever gives the same advice. One guy will say, "Symbols and numbers are important". Another will say only random ones are good. Yet another, "optimize entropy". The next says size does matter. You can't win. Is correcthorsebatterystaple good? Randall Munroe thinks so http://xkcd.com/936/. Would C0rr3ctH0r53b@tt3rY5T@Pl3 be better? Some folks will tell you yes, but it is damn hard to remember and type. Others say you fail unless it is W,!#Uxw\s$]"YQ>xmK`Q. Whatever. I personally use KeyPass and my passwords are like that last one. I don't know them at all. I imagine if we all had perfect passwords and sites had better security (proper salts and bcrypt or whatever) that the baddies would just put more energy into targeting employees that have admin rights on the systems and can get your data anyway.

Yet we're expected to give more and more personal information to these companies for their marketing purposes. It's pathetic how poor the so-called security some of these sites has actually is.

Seems to me that the penalties for poor data security are rather less than they should be. For instance, we all believe that data is worth money. If a site is storing data, then that site is storing something valuable. When we give personal data to a site, we are entrusting that value to the site, which should give the site some kind of fiduciary responsibility, IMO. The view from here is that LivingSocial should be vulnerable to a class action lawsuit with 50 million plaintiffs. Same for LinkedIn, TJ Maxx, etc.

I don't see why users aren't providing two passwords, one used to salt the other. If someone used the password "speaker12" and "window34" in conjunction with each other, the difficulty to crack the password would, from what I understand, be exponentially higher.

Unless I missed it, the article didn't specify which algorithm LivingSocial was using (LS probably didn't say, which likely means it's MD5 or part of the SHA family). Hopefully it's something along the lines of PBKDF2 with a very high work factor... if it was, then even a moderately crappy password could take a few days to crack, and a good password (not great) months to years.

On the other hand, if it was MD5, crackers have probably cracked many millions of them already (assuming LivingSocial discovered the break in immediately after it occurred), and well on their way to the same 90+% breakage that occurred for LinkedIn..

While we are debating what type of encryption should be used (something I know absolutely nothing about) it seems to me that we are ignoring the much bigger issue. These types of breaches seem to be reported almost on a daily basis. Why is it so trivially easy to hack all these websites and get their passwords and other info?

Sure, really good strong encryption is a great idea and I would agree that all websites should used all that really great super-duper encryption. But wouldn't it be an even better idea to secure your website so that they can't get to the passwords in the first place? Sure, you keep all you valuables in a safe, but wouldn't be even smarter to lock the front door so that people can't get to the safe?

As in much, much higher penalties for both the hacker AND the website that gets hacked.

For the hackers, longer prison sentences, wider range of what is considered criminal activity. If they ramped this up to say, a possible 20+ year prison term, with no exceptions for age (all tried as adults), you'd probably see a decent drop in this. As it is, 3-5 years, or just probation if you are underage, obviously is no deterrent at all.

For the website, more safe practice requirements and regulation with fines and/or other penalties for failure to use best practices. Not saying LivingSocial wasn't using best practices, but there have been far too many that haven't (cough, Twitter, Sony, TJ Maxx, cough).

The problem with the second part is best practices can be subverting by one careless mistake. Alternately, the site could have been breached by hackers using a zero-day exploit. Or, they were just sloppy in their site security. Until one knows how the hackers got the passwords one should not speculate.

For the hackers, longer prison sentences, wider range of what is considered criminal activity. If they ramped this up to say, a possible 20+ year prison term, with no exceptions for age (all tried as adults), you'd probably see a decent drop in this. As it is, 3-5 years, or just probation if you are underage, obviously is no deterrent at all.

20+ years? Really? That doesn't strike you as even slightly disproportionate? Let alone the fact that harsh sentencing has very little, if any, actual deterrent effect (look it up). You'd have a twelve year old hacker imprisoned for 20+ years?

[quote=""[Question for you lawyers, could someone launch a class action lawsuit alleging incompetence on the part of LivingSocial for doing so with any hope of success?[/quote]

I am not a lawyer, but, I have been told by lawyers that such a lawsuit, either individually or as a class, would have almost no chance of success unless you can show that you have suffered actual financial loss.

As one lawyer told me "If there's no actual money involved, what are you going to claim? That they hurt your feelings? Good luck with that."

Unless I missed it, the article didn't specify which algorithm LivingSocial was using (LS probably didn't say, which likely means it's MD5 or part of the SHA family). Hopefully it's something along the lines of PBKDF2 with a very high work factor... if it was, then even a moderately crappy password could take a few days to crack, and a good password (not great) months to years.

On the other hand, if it was MD5, crackers have probably cracked many millions of them already (assuming LivingSocial discovered the break in immediately after it occurred), and well on their way to the same 90+% breakage that occurred for LinkedIn..

While we are debating what type of encryption should be used (something I know absolutely nothing about) it seems to me that we are ignoring the much bigger issue. These types of breaches seem to be reported almost on a daily basis. Why is it so trivially easy to hack all these websites and get their passwords and other info?

Sure, really good strong encryption is a great idea and I would agree that all websites should used all that really great super-duper encryption. But wouldn't it be an even better idea to secure your website so that they can't get to the passwords in the first place? Sure, you keep all you valuables in a safe, but wouldn't be even smarter to lock the front door so that people can't get to the safe?

The problem is not necessarily a poorly secured website. The hackers could have use a spear-phishing or a zero-day exploit. The fist is technically preventable but will happen is someone makes a mistake or is briefly inattentive. The second is related to the OS and other apps needed to run the site. All have vulnerabilities waiting to be discovered. My guess is a combination of poor web implementation and a zero-day exploit were used.

But aside from the time investment, salting in no way makes cracking more difficult."

In case of hashed password breaches, time (and the associated computing power/energy) is the only thing that ever matters.

Yeah, this is an odd thing for the article to say. The only difficulty surrounding cracking hashes *is* time, so if you increase the time investment, you do make cracking more difficult. Salting especially, since it prevents rainbow table attacks, and means each password has to be attacked individually. That in turn means only the easy-to-break (8-10 character and/or dictionary based) passwords are likely to be cracked at all. I doubt they'll invest the time to brute force every single password, although of course if your password is "12345" you're still screwed.

Maybe I'm missing something, but shouldn't the salt prevent easy cracking of "12345" because it's really "12345 + salt" = unique hash? Assuming LivingSocial properly implemented the salt, then dictionary attacks should be worthless (which, according to prior Ars articles, it the primary method for cracking), and bruteforce is hardly going to be worth it (as others pointed out, you can crack anything given enough time).

So if the salt is 3 numerical digits then that means the password "12345" needs to be checked checked 1000 more times than it would be without the salt being present. I.E. do a hash on 12345000, 12345001, 12345002, 12345003...12345999, until you get a hash that matches the observed hash.

This can increase the time it takes to find a match, depending on the salting method (ie is your salt 3 numerical characters or is your salt 10 alpha-numerical characters). Also, is your salt really unique, how do you generate your salt? Is it at all predictable?

A short 5 character alpha-numerical salt will still only mean 36^5, or approx 60 million extra checks per password, which probably adds a couple of seconds of cracking time per password just using an i7 core processor, not even considering a multi-GPU setup.

The other thing is, how/where is the salt stored. Is it stored in the same place as the hashes are stored? Every time the user logs in the salt needs to be retrieved by the system, and it is probably stored with the same level of security as the hashed password, so who is to say that the person who stole the hashed passwords did not also steal the salts. Typically if you have access to the hashed passwords you will also have access to the salts.

The real purpose of using salts historically was to defeat pre-computation attacks like rainbow tables, but in the age of multi-gpu systems rainbow tables aren't really relevant anymore.

I don't see why users aren't providing two passwords, one used to salt the other. If someone used the password "speaker12" and "window34" in conjunction with each other, the difficulty to crack the password would, from what I understand, be exponentially higher.

You'd be surprised at the passwords that can be cracked using a good dictionary and some powerful rules. I recently spent less than an hour using Hashcat and a 111-million word list against some MD5 hashes that had been dumped online a few months ago. I was able to crack about 80% of 16,000-word list including hashes for "ilovetofunot", "windermere2313", "tmdmmj17" and "BandGeek2014".

All we have to do now is what's known as a "combinator" attack, which combines each dictionary word with every other dictionary word. Using that attack on the dictionary or the specific words cracked so far and there's a good chance we could crack the passwords generated by the method described here.

I'll have lot more details about my experience cracking these hashes in an up-coming feature. Stay tuned.

For any site that allows me to log in using my Google account (which, in turn, uses 2-step verification) this isn't a big deal. Thank god all my StackOverflow accounts are alright. Now excuse me while I go change the password to my bank account...

As in much, much higher penalties for both the hacker AND the website that gets hacked.

For the hackers, longer prison sentences, wider range of what is considered criminal activity. If they ramped this up to say, a possible 20+ year prison term, with no exceptions for age (all tried as adults), you'd probably see a decent drop in this. As it is, 3-5 years, or just probation if you are underage, obviously is no deterrent at all.

For the website, more safe practice requirements and regulation with fines and/or other penalties for failure to use best practices. Not saying LivingSocial wasn't using best practices, but there have been far too many that haven't (cough, Twitter, Sony, TJ Maxx, cough).

It does not matter how big the penalty is. It does not work like that. What is important is probability to get caught.