9 ms·
LivingSocial Hacked – 50 Million Customers Affected
- minimaxir 13y agoThis e-mail is important, so please read it to the end. LivingSocial must have an interesting corporate culture if the subject header of "Security Incident" isn't enough for employees to actually read the email.
- brianr 13y agoLivingSocial has thousands of employees, many in sales and other non-technical roles. That first sentence reminds them "this affects you, it's not just for the engineers." That seems prudent to me.
- danielpal 13y agoThey said they Hashed and Salted password so it's unlikely the hackers will get "actual" passwords by brute-force However what I've seen happen after this attacks is usually they attacker use the e-mail addresses to do phishing attacks and just get passwords that way. They already know their e-mail and that they are living-social customers. Expect a phishing e-mail that looks like coming from living social.
- thirsteh 13y agoHashed and salted means almost nothing. It could be one invocation of SHA-256 (or SHA512, or SHA-3) with a salt, which is fairly meaningless unless the key/password contains a large amount of entropy (almost no passwords do.) It's much more important to know what algorithm they were actually using, e.g. scrypt, bcrypt or PBKDF2, and what the settings/work factors/iteration counts for them are/were. If a company is reluctant to disclose that, they're likely using something that's highly vulnerable to parallelization/efficient brute force cracking, regardless of what kind or size of salt was used.
- StavrosK 13y agoI like how everybody is optimistic. It could have been MD5!
- integraton 13y agoSince, AFAIK, it's built on Rails, that's unlikely. However, it's possible that it's SHA-1 since popular Rails auth solutions used that by default at the time the company was founded (2007), assuming that's what they started with and never switched from.
- ukd1 13y agoI'd be very surprised if Rails didn't support upgrading the hash over time - anyone know if it does with has_secure_password?
- integraton 13y agoPrior to 3.1, Rails didn't have built-in support for password hashing or user auth beyond http auth, so it was handled by libraries (like devise or authlogic), generated code (such as with restful-auth, which was popular in 2007), or custom code. I don't think it's very common for legacy codebases to be migrated to has_secure_password, but it's not impossible. There is not built in migration for has_secure_password, AFAIK. LivingSocial is a big enough company I wouldn't be surprised if their authentication code was all or mostly custom.
- gdeglin 13y agoIt's actually very possible for hackers to still decode many of the passwords. An attacker could simply put together a dictionary of 10,000 common passwords then hash them against each user's salt value and see they they get a match for that user's password Hash. Assuming Hashes are stores as SHA-256, with a GPU hashing setup they'll be able to scan through 50 million users in very little time at all.
- gruseom 13y agoI have a dumb question about this. It was a smart question when someone asked me it the other day, but it's a dumb question now because I feel like I should know the answer and I don't. Why can't you get away with using some trivial but obscure modification of one of the standard fast hashing algorithms? It will be just as vulnerable as the standard algorithm, of course, once you know what it is. But now the attacker has to figure out which algorithm you modified and how you modified it. How do they do that? I get that this is a bad idea that won't work, blah blah security by obscurity and so on. But when I was asked why it doesn't work, I was unable to give a very satisfying answer.
- ukd1 13y agoIt would work, but a) you might break the algorithm in ways that make collisions b) if your code is stolen in a breach, it's useless. Most people should use bcrypt with enough rounds to make it difficult to brute force. scrypt is also an option, though newer (good / bad: http://security.stackexchange.com/questions/26245/is-bcrypt-better-than-scrypt http://security.stackexchange.com/questions/26245/is-bcrypt-...).
- rajivm 13y agoWell if they don't have your source code, why modify the algorithm, you can just use sha1(password + user_salt + site_secret) -- that site_secret just made the sha1 unique to your site. Of course, if they have your source code, then it doesn't matter: they would have your 'site_secret' or your modified algorithm. Better would be not storing your site_secret in a accessible way (not on disk). Edit: See udk1 below -- he's right, sha1 is an outdated algorithm for this purpose. Poor example choice on my part.
- fudged71 13y agoWould encrypting the email addresses be feasible? They do seem to have a lot of value to hackers, but I'm not sure what the technical limitations would be for a user-base this large or with their functionality.
- whichdan 13y agoEncrypting would be pointless. Hashing would be possible, but then you break things like email notifications and password resets.
- umsm 13y agoUpon a password reset submit, check if the hash(email_submit) exists, if so, email the password reset instructions to the email_submit address :)
- rozap 13y agoStill, notifications would be toast. Thought most email notifications are annoying, they can be useful (or crucial).
- umsm 13y agoIf you don't need email notifications, then it's not a problem. One nice feature from gmail/yahoo/outlook/etc.: temporary email addresses that forward to your email. This would solve the problem. Or, maybe alternative notification methods are preferred? If they wanted, a user can input an email address with a plus (if they're using gmail) and then receive notifications only on that. If the user wanted, then they could block all incoming messages that match that generated email.
- unclebucknasty 13y agoWhy is encrypting pointless if you generate the equivalent of a private key in code? Of course, if the attacker also gets the code, then you're toast, but getting the code is not guaranteed. So, seems like you'd have some additional protection with encryption.
- dcu 13y agoit's well known that many users pick passwords like "password", "123456", "qwerty", etc... so I don't think cracking many of those passwords will be a problem
- mdasen 13y agoThat's good. However, if a good proportion of people use one of the 1,000 most common passwords, then they can hack those accounts in the time it takes to compute 50M * 1,000 hashes. With CUDA, it seems that you can do hundreds of millions per second. At 100,000,000 per second, you could compute that in 500 seconds (under 10 minutes). http://www.golubev.com/hashgpu.htm http://www.golubev.com/hashgpu.htm - this claims into the billions per second. When were talking 5B tries per second, that means trying the most common 100,000 passwords against each of the 50M accounts in under 20 minutes. The most common 1,000,000 passwords against all 50M accounts in under 3 hours; the most common 10M passwords against all 50M accounts in a little over a day. Hashing is good, salting is better, but unless there was a work factor involved like PBKDF2, bcrypt, or scrypt, it seems like it's protection against people who don't know what they're doing more than against people who know what they're doing. I'm not the type to say that we need to protect against people who have the money to make ASICs (app-specific integrated circuits likely used by governments), but I do think protection against nVidia chips is warranted. Now, it's genuinely possible that by "hashed and salted", they mean they used bcrypt or PBKDF2 (and simply aren't giving details in the email). But, if it's a salted SHA1, I think phishing would be harder than cracking a substantial proportion of them.
- EvanKelly 13y agoMaybe I'm misunderstanding (entirely possible!) and I think your point still stands, but isn't it 50M * 1,000 hashes * # of possible salts? EDIT: Just realized that the salts have to be stored somewhere and the attacker probably grabbed those as well. I think that answers my question.
- mpyne 13y agoNo, because the salt is stored with the password. Salts are used to defend against reversing a password hash into a password, but they don't appreciably impede bruteforcing passwords into hashes.
- nwh 13y agoIt does mean that for a large dictionary attack things will go a lot slower. Rather than one computing one hash and comparing it to 50M hashes, the same word must be hashed with 50M different salts and then compared with their respective hashes.
- wglb 13y agoWhy would the attacker, if they got the passwords, not bother to look to the column just to the right and take the salts as well? Given that, the attacker can try hundreds of billions of password combinations per second.
- chill1 13y agoThe point of unique salts is that even if all the user's passwords are the same, the end resulting hashes that are stored in the database, are different. So, let's say you wanted to hash your set of 50,000 different, commonly used passwords. You'd have to hash that list of 50k passwords for EACH individual user. So instead of 50,000 hashes... you have 50,000 x the total number of users.
- wglb 13y agoI am not following your logic here. What I am saying that if the attacker gets a row from the database that has the user's id, the password will be in a column labeled 'password'. Next column is likely to be the salt generated for that user's password, and let's say that this column name is 'salt'. With the salt and password for each user, you can run a dictionary across each combination at a furious rate.
- StavrosK 13y agoThe attacker does, of course, have the salts as well, since they're part of the hash. I don't see how they can try hundreds of billions of password combinations per second, though.
- bcoates 13y agohttp://securityledger.com/new-25-gpu-monster-devours-passwords-in-seconds/ http://securityledger.com/new-25-gpu-monster-devours-passwor... 25 late 2012 vintage GPUs gets you 180 billion MD5 tries per second. With a fairly modest budget you can rent a whole lot more GPU power than that. A little Googling gets me several companies offering password hash cracking as a service.
- marshray 13y agoWe can expect 50% of the password hashes to be cracked in the first few minutes, 10% will never be cracked, and the 40% in between will survive with a roughly exponential decay.
- malandrew 13y agoI wouldn't be surprised if we eventually see a breach for a company where the attackers, after securing the DB of emails, goes on to email everyone informing them of the breach before the company does so and asking them to reset their passwords. This would give the attackers the old email of the person (which has likely been reused on other services) AND a new password that they also may already be using on some services or plan on using on other services in the future.
- t0 13y agoCould this be another Linode that misleads the public as to what was actually hacked in an attempt to save their public image?
- biot 13y agoCould it be that you are actually a serial killer on the run from prison? What's the point in engaging in such idle speculation? If you have actual information to discuss, great. Otherwise, it could just as well be that they are working on a comprehensive postmortem of exactly what happened with incredible amounts of detail.
- hobolobo 13y agoI think that suspecting the worst has become a default position after so many appalling breaches (RockYou, Gawker, etc). After losing their 50M entry user database one would expect them to be a bit more forthcoming.
- MWil 13y agoSo enough time has passed for the attack to reach the higherups, an internal email authored, that email leaked, the contents of the email confirmed by the company...and NO emails out to the users? What's the harm in making those two emails go out concurrently?
- jyap 13y ago"Ruby on Rails is the platform upon which LivingSocial runs." - http://en.wikipedia.org/wiki/LivingSocial http://en.wikipedia.org/wiki/LivingSocial I'm just speculating but the first thing that ran through my head is 'this must be a Rails breach'. I'm also guessing that a very large percentage of the 50 million users signed up like I did when Amazon had a deal (something like $20 gift card for $10). LivingSocial have put up somewhat of a statement on their web site asking you to change your password: https://login.livingsocial.com/forgot_password/?reset=true https://login.livingsocial.com/forgot_password/?reset=true """ LivingSocial recently experienced a cyber-attack on our computer systems that resulted in unauthorized access to some customer data from our servers. We are actively working with law enforcement to investigate this issue. The database that stores customer credit card information was not affected or accessed. Although your LivingSocial password would be difficult to decode, we want to take every precaution to ensure that your account is secure, so we are expiring your old password and requesting that you create a new one. """
- phillmv 13y agoWell, yes, you deserve what's coming to you if you run an unpatched system but that's a pretty baseless speculation.
- sdoowpilihp 13y agoI don't think he implied the system was unpatched, only that an issue with Rails may have been exploited to compromise the site. It is reasonable to posit there is an undisclosed security issue with Rails that is being exploited here.
- harryf 13y agoAt what point do we call collecting large numbers of user credentials in a central place that can be accessed worldwide a bad idea? To me this is the problem P2P should be solving, not Facebook, Google or Mozilla
- pwman 13y agoReleased late in the day on a Friday to try to minimize the news cycle and guarantee fewer people will see it.
- AUmrysh 13y agoLivingSocial messed up a meal order of mine so badly one time, I had to pay for the meal twice and they still didn't refund my payment. Worst company I've ever dealt with, and I'm really not surprised to see they have a security breach considering the awful experience I had with them and how it seemed that they just didn't know what was going on.
- deleted 13y ago[deleted]
- IgorPartola 13y agoIs it time yet that someone builds a cross-platform account management appliance? Currently, we seem to be stuck between things like Kerberos which are complex, and your framework's built-in account framework which often uses SHA-1/MD5 + salt and has no mechanism for upgrading to better alternatives. While things like Persona are awesome, for those who insist on using passwords, why not have a standard "thing" that handles them? It should be able to switch passwords schemes on the fly (via re-encryption or double encryption), store data separately from your main DB, and be all kinds of paranoid.
- phillmv 13y agoWell, you end up with something like kerberos. Horrifying complexity rarely evolves in a vaccuum. Every tried building an ecommerce platform? It's really funny. You start out as a fresh whippersnapper who is all like "MAN, stuff like spree is maddeningly complicated. We don't need something that complicated, we can just start real easy!" and fast forward three months and you've got a few white hairs, a deep hatred of paypal and something not dissimilar from what you wanted to avoid in the first place. The better alternative would be to lobby all plugin vendors to switch to bcrypt/insert preferred alternative here.
- brador 13y agoWouldn't that mean a single point of failure?
- rdl 13y agoIf you put the whole read-only auth system on a single machine, yes, but there's no reason you couldn't have an arbitrary number of these boxes. You'd presumably put a few in each cluster of frontends at scale, not one per frontend.
- rdl 13y agoYeah, doing this with an HSM would allow you to keep plaintext passwords (avoid expensive algorithms like scrypt/bcrypt) encrypted under an in-HSM key. As long as the comparisons happened in the HSM, no one would be able to steal the passwords. You could throw other heuristics in to rate limit or whatever. HSMs are pricey ($5-25k), but you could maybe lower the cost if you started using them in volume for web logins; no reason you couldn't do something protected against logical/remote attacks only for $250. Hardware attacks too, if you had high enough volume, for <$1k.
- swang 13y agoIf you goto the website they won't let you login now without reset your password. So essentially you only know there's a problem if you goto their website since they've yet to send an email. But they had time to send me some great Mother's Day Deals half an hour ago!
- biot 13y ago> But they had time to send me some great Mother's Day Deals half an hour ago! ... which their creative department had already developed based on a standard template and scheduled to have deployed today. Meanwhile, the security incident email had to be crafted and is probably winding its way through legal.
- sdoowpilihp 13y agoI would hope by this point most of those daily deals emails are automated.
- anonfunction 13y agoThat was probably scheduled in advance...
- babuskov 13y agoLooks like a neat way to ask you to go to website, which, as you wrote, forces you to reset the password. Maybe this is the way to clean up the mess and they'll only inform the users who do not click the offer ;)
- ttrreeww 13y agoSo, should I change my email password as well?
- Nogwater 13y agoIf you use your email password for any other site, yes!
- jmount 13y agoAnd there seems to be no way to delete a Living Social account (despite some language that says you can terminate the contract by canceling the account). Very 503 over there right now.
- greenmountin 13y agoIt is kind of weird, especially because there's not even an appropriate label in the dropdown menu for a help ticket. But they deleted mine 5 hours after sending it, so maybe they have a macro set up.
- danso 13y agoIs their Github account a good indication of the state of their Rails setup? This appeared to be the only Rails-related gem they've open-sourced that's relatively well-followed: https://github.com/livingsocial/rails-googleapps-auth https://github.com/livingsocial/rails-googleapps-auth The gemspec here: https://github.com/livingsocial/rails-googleapps-auth/blob/master/rails-googleapps-auth.gemspec https://github.com/livingsocial/rails-googleapps-auth/blob/m... gem.add_runtime_dependency("actionpack", [">= 2.3.5"]) gem.add_runtime_dependency("ruby-openid", ["= 2.1.8"]) gem.add_development_dependency("activesupport", ["~> 3.0"]) gem.add_development_dependency("tzinfo", [">= 0.3"]) gem.add_development_dependency("actionpack", ["~> 3.0"]) gem.add_development_dependency("activemodel", ["~> 3.0"]) gem.add_development_dependency("railties", ["~> 3.0"]) gem.add_development_dependency("rspec-rails", ["= 2.5.0"]) One of the recent critical vulnerabilities involved ActionPack, pre x.x.10: https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/61bkgvnSGTQ https://groups.google.com/forum/?fromgroups=#!topic/rubyonra... The gemspec above specifies ActionPack 2.3.5 and above...theoretically, it's possible they upgraded their Rails installation without having to upgrade this particular gem...and perhaps they don't use this gem at all anymore (hasn't been updated in 8 months), so this is all speculative. edit: Going to assume that LS at least protected from the Homakov-mass-assignment vulnerability, demonstrated in March 2012: https://github.com/rails/rails/issues/5228 https://github.com/rails/rails/issues/5228
- steveklabnik 13y agoLivingSocial has also made significant contributions to Resque, which I maintain.
- bascule 13y ago> Is their Github account a good indication of the state of their Rails setup? No. Source: former employee
- futhey 13y agoOnly used LivingSocial once, thankfully I used my simpler "Untrusted" password, and not a more secure one.
- samweinberg 13y agoYou reuse your passwords? Tsk tsk tsk...
- futhey 13y agoYes, Mother, THIS is what I'm going to wear... (heh) I'm pretty lazy when it comes to passwords for services that don't house any private information, and livingsocial's buggy UI design heavily influenced my decision to use paypal in lieu of assuming they were PCI compliant.
- AUmrysh 13y agoWhat are the implications if you logged in using Facebook connect?
- geogra4 13y agoYeah, this is what I used.
- marshray 13y agoPUBLIC SERVICE REQUEST: If the LivingSocial hashes do end up leaking will folks who work on cracking them pretty please record and publish their crack rate as it changes as progress is made over the db? We need these kinds of records kept on real-world events in order to do retrospective studies. TIA :-)
- dfadfa 13y agoYes please do. And then afterwards somebody will be able to use that to incriminate you.
- marshray 13y agoSimply cracking hashes that somebody else already leaked shouldn't be a crime and it's a common activity for network defenders and security researchers. Some fundamental concepts used by defenders like "password strength" are subtly dependent upon the abilities of a putative attacker, yet we know that attackers are evolving their skills with every new breach. Thus in order for defenders to reason intelligently about their security and resolve the numerous trade-offs they face, we need data from the widest possible variety of sources when these real-world events occur.
- tptacek 13y agoPeople have been cracking passwords and releasing stats for something like two decades now. Point to one of them who got prosecuted.
- larrys 13y agoWould you agree though that releasing the info might put you on the radar or up your "watch list" karma? I understand your point though. Similar to when I hear people on HN make statements of what could happen in business, with the IRS, or their city government (say with inspections) but from my years of experience I laugh because it is an extremely rare occurrence. "You can't claim the laptop you bought that your wife uses as a business expense if you get audited you are in deep shit!!!"
- o0-0o 13y agoIf ANYONE can figure out how to cancel a living social account, let me know. What a fucken crap site.
- tomjen3 13y agoMuch of the issue with passwords could be avoided if the sites just sends you a randomly generated password in your introduction email. That way there is no chance of re-use and if the db gets compromised, just issue a new password.
- hoka 13y agoThe body of an email I received 6:30 AM Eastern time: from <updates@livingsocial.com> " IMPORTANT INFORMATION LivingSocial recently experienced a cyber-attack on our computer systems that resulted in unauthorized access to some customer data from our servers. We are actively working with law enforcement to investigate this issue. The information accessed includes names, email addresses, date of birth for some users, and encrypted passwords -- technically ‘hashed’ and ‘salted’ passwords. We never store passwords in plain text. The database that stores customer credit card information was not affected or accessed. Although your LivingSocial password would be difficult to decode, we want to take every precaution to ensure that your account is secure, so we are expiring your old password and requesting that you create a new one. For your security, please create a new password for your (removed my email address) account by following the instructions below. Visit https://www.livingsocial.com https://www.livingsocial.com Click on the "Create New Password" button (top right corner of the homepage) Follow the steps to finish 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). The security of your information is our priority. We always strive to ensure the security of our customer information, and we are redoubling efforts to prevent any issues in the future. If you have additional questions about this process, the "Create a New Password" button on LivingSocial.com will direct you to a page that has instructions on creating a new password and answers to frequently asked questions. We are sorry this incident occurred, and we look forward to continuing to introduce you to new and exciting things to do in your community. Sincerely, Tim O'Shaughnessy, CEO"
- doomslice 13y agoI was REALLY hoping there would be no links to livingsocial in that email and that there would just be instructions to enter it in yourself. Now a phisher can copy the entire email and have that link in the yellow portion send you to a phishing site.
- imbriaco 13y agoIt doesn't really matter. A phisher could write an entirely different message with a link in it just as easily.
- katographr 13y agolivingsocial db dump with over 50M email/hashed password/salt; get a private copy by sending 1BTC to 17seaSU3C37o6z8TRG2yjE4VgVCUoQ4fPa and email katographr@hushmail.com with your sending address