Slashdot Mirror
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."
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!
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.
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
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.
If computers were people, I'd be a misanthrope.
Been on my yearly Forbidden Prefixes lists since 2004 and STILL GOING STRONG!
.
Prisencolinensinainciusol. Ol Rait!
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.
They might only be using MD5 in MySQL and calling that hashed and salted, but that is not much protection these days is it?
liberare massarum ex ignorantia, clausa descendit molestie.
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.
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?
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 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.
God invented whiskey so the Irish would not rule the world.
>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.
God invented whiskey so the Irish would not rule the world.
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.
Never use the same password twice.
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.
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.
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).
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.
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.
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*.
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.
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?
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.
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.
"Science can amuse and fascinate us all, but it is engineering that changes the world. " - Asimov.
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
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/
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.
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.
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.
This is weird. I got an email from living social this morning but I never signed up for it.
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...
Avantslash: low-bandwidth mobile slashdot.
Never use the same password twice.
Then how do you get logged back in?
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.
Well.. maybe. Or Maybe not. But Definitely not sort of.
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).
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.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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.
+1 funny and unfortunately true for some people.
-- Using the preview button since 2005
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.
Wolde you bothe eate your cake, and have your cake?
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.