Forgot your password?
typodupeerror
Security The Internet

LivingSocial Hacked: 50 Million Users Exposed 80

Posted by Soulskill
from the no-end-to-the-low-hanging-fruit dept.
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."
This discussion has been archived. No new comments can be posted.

LivingSocial Hacked: 50 Million Users Exposed

Comments Filter:
  • by Anonymous Coward

    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

    • by larry bagina (561269) on Friday April 26, 2013 @09:28PM (#43564025) Journal

      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.

      • by Bengie (1121981)
        A one time rainbow table is entirely useless.
      • by drkstr1 (2072368)
        Fail.
        • by drkstr1 (2072368)
          And for the record, the fail is in my own reading comprehension. I misunderstood the GP''s comment.
          • by RockDoctor (15477)
            Someone who re-reads their own comment, and the parent, while still thinking. And then admits it.

            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)

      by Anonymous Coward

      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.

      • by drkstr1 (2072368)

        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.

      • 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

    • by eksith (2776419)
      The salt is usually stored side by side with the salt + password hash. The salt is just a random bunch of data (of reasonable length; you can usually get away with 16 bits, but I've seen 48+ around) generated each time the user creates/changes the password. It need not be unique in the whole database, but the longer it is, the more computationally difficult it is to crack (also using an expensive hash scheme like bcrypt). I usually also encrypt the salt as well using an application specific password (this u
    • by BradleyUffner (103496) on Friday April 26, 2013 @09:42PM (#43564113) Homepage

      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.

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

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

        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.

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

      by Anonymous Coward

      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

      • by X.25 (255792)

        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.

  • I would have called it "forcing users" myself. As soon as you logged in, the screen came up and said your password was expired and to please set a new one.
  • by eksith (2776419) on Friday April 26, 2013 @09:28PM (#43564021) Homepage

    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.

  • Been on my yearly Forbidden Prefixes lists since 2004 and STILL GOING STRONG!

    .
  • by Anonymous Coward

    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

  • by fluffy99 (870997) on Friday April 26, 2013 @09:51PM (#43564165)

    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?

    • by Shados (741919)

      Most users use the same fucking password for everything!

      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

      • by fluffy99 (870997)

        Most users use the same fucking password for everything!

        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.

    • by scrib (1277042)

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

  • by larwe (858929) on Friday April 26, 2013 @09:51PM (#43564173) Homepage
    I hate the way they reassure everyone that credit card numbers weren't stolen. I DGAF who steals my credit card, because it's zero liability to me and a simple phone call will fix up any unauthorized charges. There's no identity theft possible from stealing my CC#, just some minor inconvenience. It's a MUCH more serious matter that a name + DOB pair can be stolen, because that's sufficient to lead to serious identity theft. I've taken to using 1-1-80 as my DOB on sites that ask for it, but (a) sites shouldn't ask for it - they have no need to know, and (b) there are some sites where I enrolled before I set this policy, so they have my real DOB. I don't know if LS was one of those.
    • 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

      • by larwe (858929)
        Yeah, I know about COPPA - and its meaningless requirements could be satisfied by a simple checkbox that says "Yup, I'm over 13, let me see the boobies now please, Beavis". The reason LivingSocial wants the DOB is for demographic targeting to advertisers. 19yos have less need for discount Depends than 89yos.
    • 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

    • by cdrudge (68377)

      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.

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

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

  • This is weird. I got an email from living social this morning but I never signed up for it.

Programmers do it bit by bit.

Working...