
LivingSocial Hacked – 50 Million Customers Affected - dcu
http://allthingsd.com/20130426/livingsocial-hacked-more-than-50-million-customer-names-emails-birthdates-and-encrypted-passwords-accessed/
======
marshray
PUBLIC 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
Yes please do. And then afterwards somebody will be able to use that to
incriminate you.

~~~
tptacek
People have been cracking passwords and releasing stats for something like two
decades now. Point to one of them who got prosecuted.

~~~
larrys
Would 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!!!"

~~~
marshray
The only radar that matters is the one you put in your own head. Fuck the
radar.

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

~~~
mdasen
That'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> \- 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.

~~~
twistedpair
I'm curious why I've never heard anyone suggesting to make a public/private
key pair, burn the the private key, and just encrypt passwords with the public
key as your hashing function.

Short of finding an exploit in GPG, you'd have to crack the public key used
which would be near impossible if a long key was used. This assumes you keep
that key safe.

So why not literally make a key pair and throw away the key?

~~~
bcoates
At best, that's just a hash function, so no matter how long the key is you can
still just guess passwords and do trial encryptions just like you would with a
hashed, salted password.

If you used the same key for all your site's passwords an attacker could build
a rainbow table so you don't even get to not salt.

It would be a lot slower than a normal hash so it'd be harder to brute force,
but you can get the same protection in a simpler, more predictable system by
just using PBKDF2 with enough repeated hashes.

~~~
eksith
The situation is a bit more complicated than that :
<http://security.stackexchange.com/a/6415>

I don't subscribe to one "scheme" for passwords since the easiest method (to
implement, not crack) will be the avenue malicious hackers also pursue.

This is why most of my custom jobs involve an application specific salt per
installation, in addition to the user-unique salt + password hash and then CFB
encrypt the salt using another app-specific password + username hash.

~~~
floody-berry
people actually pay you just to make shit up?

~~~
sk5t
I can't disagree with your sentiment... there comes a point where a hardware
security module makes more sense than extraordinarily convoluted, tortured
concealment of the salt and hashing mechanism.

~~~
floody-berry
It was perhaps unnecessarily blunt, but that is the root problem with most of
these leaks: Someone who doesn't know what they're doing implementing a scheme
that is only slightly more secure than storing the passwords in plaintext.

It turns out LivingSocial was actually using SHA-1 with a 40 byte salt [1].

> 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. We have switched our
> hashing algorithm from SHA1 to bcrypt.

A 40 byte salt? "_additional_ layer of protection"? "elongates the password"?
It's clear they thought they were implementing extra security (hey, let's use
a 40 byte salt instead of 16, mega protection!) but failed miserably because
they did not know what they were trying to combat.

[1] <https://www.livingsocial.com/createpassword>

------
jyap
"Ruby on Rails is the platform upon which LivingSocial runs." \-
<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>

""" 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
Well, yes, you deserve what's coming to you if you run an unpatched system but
that's a pretty baseless speculation.

~~~
sdoowpilihp
I 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.

------
minimaxir
_This 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
LivingSocial 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.

------
pwman
Released late in the day on a Friday to try to minimize the news cycle and
guarantee fewer people will see it.

------
hoka
The 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> 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
I 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
It doesn't really matter. A phisher could write an entirely different message
with a link in it just as easily.

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

~~~
brador
Wouldn't that mean a single point of failure?

~~~
rdl
If 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.

------
danso
Is 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>

The gemspec here: [https://github.com/livingsocial/rails-googleapps-
auth/blob/m...](https://github.com/livingsocial/rails-googleapps-
auth/blob/master/rails-googleapps-auth.gemspec)

    
    
    		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/rubyonra...](https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-
security/61bkgvnSGTQ)

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>

~~~
bascule
> Is their Github account a good indication of the state of their Rails setup?

No. Source: former employee

------
MWil
So 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?

~~~
enjo
I'd want to prepare my support and sales staff before sending off an
announcement to my users.

~~~
MWil
That's a fair response...now what's a reasonable amount of time for that to
take place knowing that customers are learning about it from third parties?

------
swang
If 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

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

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

------
harryf
At 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

------
jmount
And 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
It 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.

------
AUmrysh
What are the implications if you logged in using Facebook connect?

~~~
geogra4
Yeah, this is what I used.

------
t0
Could this be another Linode that misleads the public as to what was actually
hacked in an attempt to save their public image?

~~~
biot
Could 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
I 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.

------
o0-0o
If ANYONE can figure out how to _cancel_ a living social account, let me know.
What a fucken crap site.

------
futhey
Only used LivingSocial once, thankfully I used my simpler "Untrusted"
password, and not a more secure one.

~~~
samweinberg
You reuse your passwords? Tsk tsk tsk...

~~~
futhey
Yes, 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
LivingSocial 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.

------
ttrreeww
So, should I change my email password as well?

~~~
Nogwater
If you use your email password for any other site, yes!

