LivingSocial Hacked: 50 Million Users Exposed 80
wiredmikey writes "Daily deals site and Groupon competitor LivingSocial said on Friday it had fallen victim to a cyber attack that put its roughly 50 million users at risk. 'LivingSocial recently experienced a cyber-attack on our computer systems that resulted in unauthorized access to some customer data from our servers,' the company said in a brief note on its site while prompting users to reset their passwords. Attackers reportedly obtained information including names, email addresses, date of birth for some users, and passwords, which fortunately were hashed and salted. Additionally, the database holding credit card information was not accessed by the attacker, the company said. 'While it is good that the passwords stolen from LivingSocial are hashed and salted as this likely slow down the cracking process, it won't stop it,' Rapid7's Ross Barrett said. 'Once they had cracked the first round with the tools at their disposal, they posted the hashes in a Russian hacker forum where other motivated individuals with the necessary skills and more advanced cracking tools were able to help decode the remaining passwords,' Barrett continued. 'While salting the passwords will slow this process down further, eventually the attackers or their network will get the information they're after.' LivingSocial said they are actively working with law enforcement to investigate the incident but have not provided any additional details."
How do admins keep salts secure? (Score:1)
I admit to not having practical knowledge about salted hashed passwords (but I do enjoy salty hash for breakfast). I've wondered how admins secure the salt, which I understand is combined with the user-entered password, hashed, then compared with the stored,salted password - I'm assuming the same salt is used for producing the stored salt-hashed password, and for producing the salt-hashed query against the stored password to validate a login - so I may be wrong on how that works.
It seems like if the hackers
Re:How do admins keep salts secure? (Score:5, Informative)
every user gets a random salt. If you know the salt, you can generate a rainbow table for it. But, again, every user has a different salt so you need to generate a rainbow table for every user.
Generating a one-time rainbow table that cracks every password ever is easier than generating a rainbow table per password.
Re: (Score:3)
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
Get thee off Slashdot! Thee art a witch, a heathen and a heretic and thee art lucky thee is not already on the barbecue!
Re: (Score:3, Informative)
The point of the salt is that previously generated and downloadable rainbow tables are of no use. Making new ones would kindof defeat the purpose, as you're effectively brute forcing a tough, hashed password anyway at that point.
This is why it's good practice. It helps mitigate complexity concerns over user supplied passwords, and can make cracking multiple account pwd hashes unrealistic.
Re: (Score:2)
The point of the salt is that previously generated and downloadable rainbow tables are of no use. Making new ones would kindof defeat the purpose, as you're effectively brute forcing a tough, hashed password anyway at that point.
This is why it's good practice. It helps mitigate complexity concerns over user supplied passwords, and can make cracking multiple account pwd hashes unrealistic.
I should have just modded this up instead of posting my one word comment. My bad.
Rainbow tables are still useful, even with salt (Score:2)
The classic Unix password salt was 12 bits, and that was good enough to help protect a good 8-character password on a PDP-11 or VAX or even a Sun-3, back in the days when everybody could still read the password file. It did stop you from building a rainbow table that covered all 56 bits of password space, and even today there are very few (if any) organizations that can store that big a rainbow table.
But rainbow tables don't need to store the whole password space to be useful. A rainbow table of 1000 over
Re: (Score:2)
Re: (Score:2)
Re:How do admins keep salts secure? (Score:5, Informative)
The salts aren't meant to be secure. They are commonly stored in plain text right next to the password in the database. The salt's actual job is not to prevent a hacker from breaking that user's password, but to prevent the hacker from being able to break all the passwords at once. The salt effectively "messes up" the hash of the password so that that even if multiple user's have the exact same password they will have different hashes. We all know many users use "1234" as their password. If each user has a random salt applied to the password and if the hacker guesses one user's password, he can't look at all the other users with the same hash and know that they all have the same password. The hacker has to spend the time cracking each password individually.
Re: (Score:2)
The salts aren't meant to be secure. They are commonly stored in plain text right next to the [password hashes] in the database. The salt's actual job is not to prevent a hacker from [cracking] that user's [password hash] [and discovering the password], but to [slow] the hacker [down by preventing them] from being able to [crack] all the [password hashes] at once. The salt effectively "messes up" the hash of the password so that that even if multiple user's have the exact same password they will have different [password] hashes. We all know many users use "1234" as their password. If each user has a random salt applied to the [password hash] and if the hacker [cracks] one user's [password hash], he can't look at all the other users with the same hash and know that they all have the same password. The hacker has to spend the time cracking each password [hash] individually.
FTFY.
Re: (Score:3)
That may be *part* of a salt's usefulness. Another possibly bigger part is to prevent rainbow table attacks, i.e. making it so a cracker can't just take a precomputed list of hashes of common passwords and match them to what's in the database.
hard to feel sorry for them (Score:1)
I recently got an email from Living Social welcoming me and the I started getting spammed. Of course, I had never signed up and there was never any "click here to confirm" type email. Fortunately my mail provider (Gmail) can easily filter out and delete anything from them before I ever see it. But now I guess I'll start getting more spam as well.
As to how they got my email in the first place, I do protect it by only giving out Spamgourmet addresses, but my Gmail address is simply my last name, so it ends
Re: (Score:2, Insightful)
THEY SEND ME EMAILS, SO THEY SHOULD BE THE VICTIM OF CRIMES
Yes, that sounds like a very well-measured and thought-out response. Well done, sir. Especially since the culprit for the emails is probably a typo when someone else signed up, if you have a simple last-name-only email address
Re: (Score:2)
Yes, that sounds like a very well-measured and thought-out response. Well done, sir. Especially since the culprit for the emails is probably a typo when someone else signed up, if you have a simple last-name-only email address
It is really hard sending a confirmation email.
I mean - really really hard.
Especially in year 2013.
Prompting Users? (Score:2)
Re: (Score:2)
Good. Letting people go on using a compromised password is silly.
Re: (Score:2)
I wish more people plan for "when" instead of "if" (Score:4, Insightful)
Sure, you can throw whatever current best practices are toward keeping your data secure, but let's at least have a plan B for when things really do go horribly wrong. Because if it can, it eventually will.
I don't like sticking to just one method for passwords because malicious hackers usually try the methods that are easiest to implement (whether one type of algorithm or a set number of iterations etc...) the difficulty in cracking is usually second and, let's be honest, changes day by day as GPUs, FPGAs and so on get faster and faster and can run in parallel. This is why you should try some combination of HMAC, bcrypt etc... (nothing too "new", too fast or DIY please)
The emails are unfortunate, since now these people are prime targets for phishing (unless they've seen this report, but even then, they might think "Oh, I should change my password! Let me click on this link that totally looks like it's from Living Social). Also of note, they should have done more to protect the birthdays most of all. That's what some people use for passwords still and I've seen it being thrown around in those "password reminder" questions. Some financial institutions even accept those in lieu of the mother's maiden name.
Re: (Score:2)
>The emails are unfortunate, since now these people are prime targets for phishing
Not just phishing. Do you realize how many sites now use your email address as your username? I just had to go and change not just my LivingSocial account, but half a dozen others, too, that used the same email/password combination. This is a serious pain in the ass.
Re: (Score:1)
Never use the same password twice.
Re:I wish more people plan for "when" instead of " (Score:5, Funny)
Never use the same password twice.
Then how do you get logged back in?
Re: (Score:2)
Either that's a nice joke, or you don't understand that he was talking about using a unique password for each site.
In any case, something like OATH as a second factor works pretty well as an additional measure of security.
http://en.wikipedia.org/wiki/Initiative_For_Open_Authentication [wikipedia.org]
Wish more sites supported it.
Re: (Score:3)
I assume you've learned your lesson are not reusing passwords now, are you?
If you think it's too hard to remember them all, just use a password manager. Keepas, LastPass (this is not open so it could be vulnerable), etc.
Re: (Score:2)
+1 funny and unfortunately true for some people.
"Cyber-" (Score:2)
.
Re: (Score:2)
They might only be using MD5 in MySQL and calling that hashed and salted, but that is not much protection these days is it?
Re: (Score:3)
They actually state: "LivingSocial passwords were hashed with SHA1 using a random 40 byte salt." Source: https://www.livingsocial.com/createpassword [livingsocial.com]
I'm glad they aren't using MD5, but wish they were using at least SHA-256 (SHA-1 has had flaws exposed [google.com]). Or ideally bcrypt [codahale.com].
Honestly, as a web developer myself, there really is no reason not to use bcrypt.
Re: (Score:2)
What kind of security flaws do MD5 and SHA-1 have that are relevant for password hashing? As far as I understand, those weaknesses are about attackers who may specially craft pairs of messages (passwords) that have the same hash, not about constructing a message that will generate a given hash without prior knowledge of the message.
The main thing that matters is how much effort it is to find a password by brute force and in that sens
Re: (Score:2)
Can you explain this a bit more?
If the hackers didn't get the salt, and only have the salted hashes, and let's say the salt is, say, a 20 character random phrase using numbers, letters and symbols, what is the weak spot?
I'm sure many /. users are implementing systems like this using salted hashes, so if there's an inherent weakness (other than the salt becoming exposed) I'm sure it would be useful if there was a straightforward explanation.
Re: (Score:2)
>let's say the salt is, say, a 20 character random phrase using numbers, letters and symbols, what is the weak spot?
The weak spot is in your supposition that they used a salt that strong. That's a huge stretch to make and I think it's highly unlikely they did so. They could've used a two-character salt and still, technically, have used salted and hashed passwords. Doesn't mean it'll take very long to crack them, though.
Re: (Score:1)
Do rainbow tables exist for many different salt insertions? I thought a rainbow table has a bunch of hashes for a bunch of unsalted passwords but even if you have a two character salt and it's the same salt for every password in your organization won't you then need a rainbow table for every password that goes with that salt? How many existing rainbow tables are there for different salt insertions? Even if you know the salt you must still brute force every possible password that goes with the salt, an exist
Re: (Score:1)
Can you explain this a bit more?
If the hackers didn't get the salt, and only have the salted hashes, and let's say the salt is, say, a 20 character random phrase using numbers, letters and symbols, what is the weak spot?
I'm sure many /. users are implementing systems like this using salted hashes, so if there's an inherent weakness (other than the salt becoming exposed) I'm sure it would be useful if there was a straightforward explanation.
The size of the salt is relevant only insofar as you want to be sure that each user has their own unique salt. The salt is stored in plaintext (or, I suppose, it could be encrypted, but then the decryption key must then be stored in an accessible place). The point is that the crackers must be assumed to have recovered the salts.
So now those salts protect you against pre-computed hashes. The cracker has to attempt each password individually. But most people use one of the few thousand most common passwords.
Re: (Score:2)
Which is just "hashing" by another name. You're exchanging one "one-way" function for a different "one-way" function that just takes longer.
You still need to be randomly salting each user's password so that the attackers cannot use a single pre-computed rainbow table against you.
Re: (Score:2)
Re: (Score:1)
And yet, with no extra effort on Living Social's part -- simply by choosing a bcrypt library instead of a custom hash/salt scheme -- even a user with a weak password would be protected.
So, sure, I might agree with you, but that doesn't absolve Living Social.
Re: (Score:2)
Who said it was a custom hash/salt scheme? Pretty much all mainstream languages used to make web apps with have built in, very secure ways to create strong hash/salts that are virtually impossible to break.
Re: (Score:1)
Assuming the cracker has access to the salt and a GPU, the only thing keeping users safe now is the entropy inherent in the passwords they chose.
It doesn't have to be like that. Instead of plugging in Good Salted Hashed Password Library, you can plug in Bcrypt Library or Scrypt Library *and protect even the users who chose bad passwords*.
Re: (Score:2)
Except that anyone using whatever is baked in their language of choice these days is already deriving a key from the salt then going from there. My cryptography knowledge is a little rusty, but I fail to see what a separate library can do beyond that?
Besides, if the machines got hosed to the point they could get the salts, they can get the secret from which keys are being derived and go from there anyway.
Re: (Score:1)
The key derivation functions can be literally several orders of magnitude harder to brute force. And their difficulty can be chosen with simple parameters, with sane defaults. There is really no comparison between a singly salted hashed password and bcrypt/scrypt.
Check out table 1 in this paper to get a sense: https://www.tarsnap.com/scrypt/scrypt.pdf [tarsnap.com]
Re: (Score:1)
Also, the whole point is that key derivation is slow. Of course the "secret from which keys are derived" is available (it is necessarily so; it's stored, along with the cost factor, as part of bcrypt's output, for example). But the fact that you have to through 2^N iterations, where N is usually >= 10, throws a meaningful speedbump in front of high-speed cracking. Now instead of brute forcing any given 7-character alphanumeric case-sensitive passwords in ~half an hour, it'll take you > 20 days on aver
Re: (Score:2)
The SQL user account that has access to the user/hash/email should not have access to the table, but only a function or sproc. This way a compromised user cannot j
Re: (Score:1)
This is completely orthogonal to the fact that salted hashed passwords have never been an appropriate means to store a password. http://codahale.com/how-to-safely-store-a-password/ [codahale.com]
Re: (Score:2)
I just have a gut reaction against security through artificial inefficiencies instead of regular math, physics, and scaling.
But then again, so many people have such horrible passwords. All about scrypt.
Re: (Score:2)
It is fortunate because using a salt increases the complexity of cracking all passwords. A salt's purpose isn't to increase an individual user's password strength, but to increase the strength of the whole database. A salt makes it so that even if user1 and user2 have "12345" as their password, they each have an individual salt applied, so when a security breach happens, the hacker has to now crack each password individually - even though user1 and user2 had the same password, the work required to crack use
Re: (Score:1)
I agree that there is no excuse not to use bcrypt.
You can do basically attempt all 8 character passwords in a few minutes per user on modern hardware (the salt adds 0 computation complexity, but as you say, it forces you to actually have to do the calculation instead of doing a lookup).
Rapid7? (Score:1)
Having dealt with this company several times, all I have to say is FUCK rapid7. I've never seen more boiler room style sales tactics by a company. Telling one person that another person had agreed to a meeting when those two people are in offices across from each other and one was in the other's office when the first call came in? Yep, several times morons from Rapid7 did just that. They only stopped with their twice weekly calls when we told them we wouldn't be working with them EVER because of how the
Now the real problem (Score:5, Insightful)
Most users use the same fucking password for everything! Living Social should be telling their users that despite the salted hashes, they should start changing all their website passwords that even look remotely similar. Of course they are also ignoring the fact that compromised systems can do more than just expose a database. Are they sure they intruder didn't figure out how to capture the passwords as people were authenticating? Are their private SSL certs still private? Why the hell are they even keeping the credit card info anyway?
Re: (Score:2)
To be fair, its almost unreasonable to ask an average non-techy user to do anything else. Passwords are simply a flawed system.
I use keypass to autogenerate different passwords and save them in its database. That works great, for someone who takes security a little more at heart. I end up having to use its very convenient search feature to find my passwords, because at this point I have something like 50-80 of them.
Now, anyone who isn't a sophisticate
Re: (Score:2)
To be fair, its almost unreasonable to ask an average non-techy user to do anything else. Passwords are simply a flawed system.
I use keypass to autogenerate different passwords and save them in its database. That works great, for someone who takes security a little more at heart. I end up having to use its very convenient search feature to find my passwords, because at this point I have something like 50-80 of them.
Now, anyone who isn't a sophisticated enough user won't do that. You want them to learn 50+ totally distinct passwords? Or you want them to learn a little tricky or mnemonic when picking passwords so they have a way to reverse them from whatever website they're used on while being different?
Yeah, most users will seriously prefer dealing with identity theft than with that at the end of the day. Flawed system is flawed.
Sadly you're right. Users should at least be smart enough to make the distinction between fluff social media sites and important stuff like their banking password. But again, way too many people use the last 4 digits of their phone number, their birthdate, or their soc number as their pin.
Re: (Score:2)
They really should!
Maybe that's why they did...
From the email LivingSocial sent me:
We also encourage you, for your own personal data security, to consider changing password(s) on any other sites on which you use the same or similar password(s).
Wrong priorities, as usual (Score:5, Interesting)
Re: (Score:2)
Websites care about COPPA, not your birth date (Score:2)
The Children's Online Privacy Protection Act requires that certain types of websites ask for birth dates so that parental consent can be obtained before a child under 13 signs up. Maybe the site has no personal reason to know your birthday, but they could get in some serious trouble for failing to ask. See, for a brief overview, http://en.wikipedia.org/wiki/Children's_Online_Privacy_Protection_Act [wikipedia.org]. Those of us lucky enough to live in California have an even stricter version at the state level.
Anyone who
Re: (Score:2)
Re: (Score:2)
Yeah, I was going to post that if I was using this service, I wouldn't be bothered, as everyone gets something different:
1) A different email address for every service and company (advantages of owning my own domain - no Gmail + plus is not enough, come on, a domain can be less than $10 a year, and just forward a catch-all to Gmail if you insist on using it).
2) A different password for every website.
3) A different DOB for every website that insists on asking.
4) Sometimes even a different name, depending on
Re: (Score:2)
Yeah, because your name and DOB pair is SOOOOO hard to find on the internet. It's not as if there are hundreds or thousands of different websites that post that type of information, either from other marketing databases, direct public records, birth announcements from $AGE years ago, etc.
While GAF about where you're birth date is submitted now is noble and all, that battle really was lost a LONG time ago.
Facebook Connect (Score:2)
I used facebook connect-- I don't have a password to reset. It still asks me, which is confusing. But I guess I'm all good?
Re: (Score:1)
I also didn't have a password to reset due to using Facebook Connect, so I believe we don't have (much) to worry about.
However, I decided it wasn't worth the off chance the could use it, so I decided to revoke LivingSocial permissions from my Facebook App Settings.
Unsolicited email notification (Score:2)
Re: (Score:2)