LivingSocial Hacked: 50 Million Users Exposed

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

Comments

How do admins keep salts secure?

[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 obtain the salt, then it is a matter of generating rainbow tables using the appropriate hash algorithm and salt, which would greatly speed up cracking the stored passwords.

So the question is, how do admins secure the salt such that a hacker cannot grab it from disk or memory.

Flay me if I'm not making sense :)

Thanks!

Re:How do admins keep salts secure?

[larry bagina]

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:How do admins keep salts secure?

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

Re:How do admins keep salts secure?

[eksith]

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 usually doesn't change between installations) and the username combined to create a "salt password" (this too is a hash). The important thing is that the password is never stored anywhere as-is.

Re:How do admins keep salts secure?

[BradleyUffner]

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:How do admins keep salts secure?

[Bengie]

A one time rainbow table is entirely useless.

Re:How do admins keep salts secure?

[drkstr1]

Fail.

Re:How do admins keep salts secure?

[drkstr1]

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.

Re:How do admins keep salts secure?

[drkstr1]

And for the record, the fail is in my own reading comprehension. I misunderstood the GP''s comment.

Re:How do admins keep salts secure?

[Bengie]

I like to use 32bytes of crypto-grade random.

Re:How do admins keep salts secure?

[VortexCortex]

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:How do admins keep salts secure?

[sacrilicious]

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.

Re:How do admins keep salts secure?

[Anonymous Coward]

To expand on this: Rainbow tables are the state of the art for an attack which spends (CPU/GPU) time and (storage) space in advance of the breach in order to significantly reduce the time needed during after the hashes have been stolen. For example you spend one week and 2TB of disk building a Rainbow table before the break-in, and then 10 seconds per password retrieved instead of spending 10 hours per password with no up-front cost. Once you're working on the eighteenth password the work needed up front has paid for itself.

With salt the work needed up front is multiplied by the number of possible salt values. With a large salt, this means the Rainbow table will always cost more than just trying to break each individual password separately, and indeed that's what bad guys now do against serious password algorithms. If users choose bad passwords it's still enough, no algorithm can prevent bad guys from figuring out that you used 123456 as your password, but with salt every individual's passwords are being attacked separately, if your password is good it'll hold out longer regardless of other people's choices.

Re:How do admins keep salts secure?

[Anonymous Coward]

Pretty sure thats exactly what he was implying.

Re:How do admins keep salts secure?

[RockDoctor]

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!

hard to feel sorry for them

[frovingslosh]

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 up getting hit by spammers doing phone book type attacks.

Re:hard to feel sorry for them

[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

Re:hard to feel sorry for them

[Anonymous Coward]

Eye for an eye. Fuck you

Re:hard to feel sorry for them

[Anonymous Coward]

THEY were not the victim, the users were the ultimate victims, after all it is them who will now have to worry about how much if any personal information was compromised, who has it, etc,

Re:hard to feel sorry for them

[X.25]

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?

[IdolizingStewie]

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.

Re:Prompting Users?

[flimflammer]

Good. Letting people go on using a compromised password is silly.

Re:Prompting Users?

[IdolizingStewie]

Indeed. I fully approve. I just wanted to make it clear that they didn't just send an email that asked nicely.

"...technical 'hashed' and 'salted'"

[Anonymous Coward]

There you go. Not every company keeps plain passwords - that's the first step towards the security.

Someone could make a fortune...

[Anonymous Coward]

Someone could make a fortune selling drone strikes hitting hackers. Seriously, if someone stole my identity, I'd have no problem taking "my own" life. Suicide is only illegal in some states, and if you're erasing "yourself" in other countries that don't have extradition agreements, all the better.

I wish more people plan for "when" instead of "if"

[eksith]

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.

"Cyber-"

[RevWaldo]

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

.

Hashed and salted is obsolete

[SUB7IME]

Why is it "fortunate" that the passwords were hashed and salted? Unless they've used key derivation functions (e.g., bcrypt, scrypt) and are actually under-selling their sophistication, this seems Very Bad for their customers.

Re:Hashed and salted is obsolete

[bejiitas_wrath]

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:Hashed and salted is obsolete

[Albanach]

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:Hashed and salted is obsolete

[corbettw]

>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:Hashed and salted is obsolete

[Bengie]

There isn't enough energy in the Universe to break a strong password that has been hashed and salted. Just make sure you use strong passwords.

Re:Hashed and salted is obsolete

[Anonymous Coward]

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 existing rainbow table of passwords with no salt isn't going to help you any. Unless there are many existing rainbow tables for many different short salts and they used a short salt and this short salt is already listed by an existing rainbow table since many short salts are. If not then what's the difference if the salt is 2 or 20 characters? It shouldn't make a difference. You would still have to construct a new table or do a new brute force for every password. Though I guess if it's only two characters you can construct a new table and store it for future slated password lists that may use the same salt.

I agree that having a separate random salt for every password and storing the salt somewhere is more secure than having a single salt for all passwords. Then you must brute force every password with different salts. Even if you have the salt list it's still difficult because every password must still be separately brute forced. But somehow I get the sense that most people on Slashdot don't really know what they're talking about. This doesn't only apply to cryptography either, it seems to apply to many fields. Oh well, such is the typical slashdot reader I suppose.

Re:Hashed and salted is obsolete

[Anonymous Coward]

Their FAQ says the salt is 40 bytes (https://www.livingsocial.com/createpassword):

What kind of protections do you use to protect my password and how does it work?
LivingSocial never stores passwords in plain text. LivingSocial passwords were hashed with SHA1 using a random 40 byte salt. What this means is that our system took the passwords entered by customers and used an algorithm to change them into a unique data string (essentially creating a unique data fingerprint) – that’s the “hash”. To add an additional layer of protection, the “salt” elongates the password and adds complexity.

Re:Hashed and salted is obsolete

[SUB7IME]

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:Hashed and salted is obsolete

[Anonymous Coward]

errr ... don't know how that last post got so messed up. "for future salted password lists" and the sentence reading "won't you then need a rainbow table for every password that goes with that salt?" should read "won't you then need a rainbow table containing every password that goes with that salt?"

Re:Hashed and salted is obsolete

[SUB7IME]

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. And inexpensive modern hardware lets you attempt billions of SHA hashes per second. So... Salted and hashed does very little for you at this point.

Instead of salting and hashing, use a key derivation function (e.g., bcrypt, scrypt).

Re:Hashed and salted is obsolete

[Shados]

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:Hashed and salted is obsolete

[SUB7IME]

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:Hashed and salted is obsolete

[Bengie]

I would go so far as to say that user/pass/email should not be stored in the same system and should not be be able to be read out of the system that stores it. It should be in an entirely separate system where your auth request can pass in a user+hash and get back if it was valid, but should not every return what the current user/hash/email is.

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 just dump the data directly from the table, but must request one user at a time, which means knowing each user.

Also, because this is a separate system, it can use very well-formed messages since they're only used for auth reasons anyway. Because of this, one could make some very strict firewall rules that make it near impossible to dump the current table and send it anywhere.

It could be taken yet another step further. When a session is started, that session may only be associated with one login, which gets assigned on a valid auth attempt. Whenever you try to auth, your session identifier must be passed in and if it's already set, then the auth will reject the request, forcing the hacker to reestablish a new session before attempting another auth. Then you can place a new-session rate limit per IP.

So, a compromised web app or even database does not give the hacker a user/hash/email
If they want to attempt access to said info, they would need to bounce a hack from an external service like a web app to the auth system, which can't talk to the Internet directly. Then the auth system would be heavily locked down as all incoming and outgoing messages are well-formed, potentially UDP of fixed lengths, and even then, gaining access to the DB as the current user would only be good for one request at a time.

I'm sure there is always a way in, but one could make it quite hard without much work.

Re:Hashed and salted is obsolete

[Shados]

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:Hashed and salted is obsolete

[SUB7IME]

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

Re:Hashed and salted is obsolete

[SUB7IME]

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/

Re:Hashed and salted is obsolete

[SUB7IME]

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

Re:Hashed and salted is obsolete

[WedgeTalon]

They actually state: "LivingSocial passwords were hashed with SHA1 using a random 40 byte salt." Source: https://www.livingsocial.com/createpassword

I'm glad they aren't using MD5, but wish they were using at least SHA-256 (SHA-1 has had flaws exposed). Or ideally bcrypt.

Honestly, as a web developer myself, there really is no reason not to use bcrypt.

Re:Hashed and salted is obsolete

[WedgeTalon]

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 user1's password is worthless to crack user2's password. Combine that with a strong hash - like bcrypt - and the amount of work to break every password is extremely costly.

The very minimum a site should use these days is SHA-256. However, the really is no excuse not to use bcrypt. If a site is using MD5, it might as well be plaintext.

Re:Hashed and salted is obsolete

[hankwang]

I'm glad they aren't using MD5, but wish they were using at least SHA-256

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 sense, you should use no hash algorithm that is designed for computational efficiency (as explained by your bcrypt link).

That said: I used to have an encrypted home directory on a netbook with an Atom processor; the encrypted filesystem (ecryptfs) used some kind of slow hash function -- that would generate about 5 seconds delay upon login and even upon unlocking the screen. So, take it easy with those slow hash functions...

Re:Hashed and salted is obsolete

[SUB7IME]

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

Re:Hashed and salted is obsolete

[WuphonsReach]

Instead of salting and hashing, use a key derivation function (e.g., bcrypt, scrypt).

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:Hashed and salted is obsolete

[Bengie]

salted+hashed passwords are fine for strong passwords.

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.

Rapid7?

[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 they pursued us.

news for nerds?

[Anonymous Coward]

How is this news for nerds? Nobody here cares unless it involves Linux, BSD, or Irix.

Now the real problem

[fluffy99]

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:Now the real problem

[Shados]

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.

Re:Now the real problem

[fluffy99]

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.

Re:Now the real problem

[Anonymous Coward]

Or, you know, they could make a warped sentence password, throw in a date of birth and have an equally strong password as your generator.
Something like a quote with different words.
Then to make each site unique, add a simple word/number at the end that you identify with each site, store it in a phone, done. (or remember it)
Or have groups of them for website groups to cut down.

You don't need a password generator. It isn't worth it and isn't more secure. They still have the "same" character count in the end. (given the sentence is large)
I use something similar to this method and a simple 2D grid with letter groups to encode a service name. Memorised it easily.
Unique password count is probably around 40-50, no problems here.
I carry my DB mentally, if your machine got stolen / hacked... bad times.

Re:Now the real problem

[scrib]

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

[larwe]

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.

Re:Wrong priorities, as usual

[Anonymous Coward]

Reversing charges is not always as simple as you think it is. You should care more about who steals your credit card.

Re:Wrong priorities, as usual

[magic maverick]

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 the reason for asking for the name.
5) Fake residential addresses etc. in certain cases.

All this information then gets saved together, along with the the information about the website or company, and the date I signed up. I then have proof (enough for me), if someone sells my email address (or otherwise loses it), and I don't have to worry about any other services or websites being compromised.

Re:Wrong priorities, as usual

[larwe]

Look, there are laws that guarantee limited liability on unauthorized CC transactions. And the absolute worst case, assuming the CC company disbelieves me when I tell them it's an unauthorized charge, I incur ONE fake debt that I could, if I choose, walk away from. One hit on my credit, one time. Identity theft is the gift that keeps on giving - short of dying and being resurrected, there is no way to stop it from popping up again and again and again.

Re:Wrong priorities, as usual

[cdrudge]

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.

Re:I wish more people plan for "when" instead of "

[corbettw]

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

By me, I think I've got it.

[Anonymous Coward]

just for one second imagine a site where you didn't need to join up with to be an active member of the community, if such a thing existed no one would ever be able to hack my account and post as me :(.

such is life as Anonymous Coward, nothing ever works out right.

Re:By me, I think I've got it.

[Anonymous Coward]

Sorry, 2ch stole your idea years ago.

Re:I wish more people plan for "when" instead of "

[Anonymous Coward]

Never use the same password twice.

Huh?

[Anonymous Coward]

What the hell is wrong with the links in TFS?

Websites care about COPPA, not your birth date

[dtgibson]

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. Those of us lucky enough to live in California have an even stricter version at the state level.

Anyone who was once thirteen can guess whether or not a thirteen-year-old will actually ask for their parents permission before clicking through, but thats another issue.

Re:Websites care about COPPA, not your birth date

[larwe]

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.

Facebook Connect

[havardi]

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:Facebook Connect

[G33kDragon]

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.

Re:I wish more people plan for "when" instead of "

[Isaac Remuant]

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.

Unsolicited email notification

[stevegee58]

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

Re:Unsolicited email notification

[VortexCortex]

I signed up for you.

Re:I wish more people plan for "when" instead of "

[webnut77]

Never use the same password twice.

Then how do you get logged back in?

Re:I wish more people plan for "when" instead of "

[Bill, Shooter of Bul]

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

Wish more sites supported it.

Rainbow tables are still useful, even with salt

[billstewart]

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 overly common passwords are enough to catch a non-trivial fraction of real-world passwords, and a table for 64K passwords with a 12-bit salt will still fit on a cheap thumb drive, though if you want to handle a million still-too-easy passwords, you'll probably want to use rotating disks. If you're trying to break root's password, hopefully root has more sense than to use a wimpy password. If you're trying to crack some user's email account to send spam from, or a blog account to drop comment spam, and don't care whose, there's probably somebody using weak passwords.

So if you're building a password system, and you're going to bother adding salt, please use at least 64 bits of it, or preferably 128 bits. Make the attacker do at least some per-victim work, even if the user's not going to bother.

Re:I wish more people plan for "when" instead of "

[MysteriousPreacher]

+1 funny and unfortunately true for some people.

Again?

[Anonymous Coward]

Didn't this happen to them once before?
That's why I left and never went back.