
EHarmony Confirms Password Hack  - danso
http://www.pcmag.com/article2/0,2817,2405453,00.asp
======
Lukeas14
If this is part of the same attack that hit LinkedIn and Last.fm are there any
theories on what the exploit was? I'm having a hard time imagining how someone
could steal passwords from 3 large, completely independent web services at the
same time.

~~~
tzs
It's possible that these were accumulated at very different times, by very
different exploits, and possibly by very different people, and ended up in the
hands of one group that released them together.

I saw speculation that the easy to break ones have already been long broken
and exploited, and this release is the ones that weren't easy. That could
explain why all three were dumped at the same time...they basically just went
through and dumped the ones they couldn't use from all of the accumulated
lists.

------
stcredzero
Couldn't password databases be implemented as hardened "appliances?" This
wouldn't have to be sold as hardware, it could just be an install.

The machine would only have the function of storing and verifying passwords,
and secure communication with authorized clients. All apis could use fixed-
length fields.

Passwords themselves could be stored using a modified salting technique using
a white-box version of block cipher. This would make it much harder for
attackers to crack the password database.

The block cipher used for the modified salt could also be implemented by
separate hardware, which would make it much harder to crack the password
database.

~~~
Lukeas14
I don't think the problem is that storing passwords is too hard, at least not
for the majority of startups not dealing with PCI compliance. Setting up a
user system with bcrypt/scrypt is pretty trivial. The problem is you have
several apps that were built before "just use bcrypt" became a meme and
switching to bcrypt or some kind of hardened "appliance" just isn't seen as a
priority, especially if it would require changes in several legacy systems.
It's like telling people to backup their databases. Everyone knows they should
do it. It's not hard. But it doesn't directly bring in revenue so therefore
some people will inevitably just never get around to it (until they get get
hacked and it becomes a PR issue).

~~~
pbreit
_Beginning_ to use bcrypt/etc may not be that hard but migrating existing
users from some other scheme to bcrypt/etc takes a bit more thought and
planning. And the "use bcrypt" crowd _never_ provides any guidance on that.

~~~
jleader
I've heard 2 ways to do it:

1\. Add a flag column to your password database; whenever anyone signs in
without the flag set, encrypt their password the old way (for checking against
their old entry in the database) and the new way (for storage in the database)
and set their flag. The only trouble is, users who never log in don't get
migrated.

2\. It's possible to treat the old encrypted form of the password as if it's
plaintext, salt that, encrypt with bcrypt, and store the result in the
database. Then password checking becomes: encrypt password with old algorithm,
salt, encrypt with bcrypt, and check against the database. It lets you convert
everyone at once, but makes the login code a little more complicated, forever.
If you can't convert everyone's database entry at once, you might still want a
flag column, so you can migrate more gradually.

There are still all the usual headaches of QA, release management, etc., but
presumably you already know how to handle them. What else am I missing?

------
kibwen
Perhaps users would be better served by salting their passwords manually
before signing up for any web services. If your usual throwaway password is
"Passw0rd1", try "eharmonyPassw0rd1" for your eHarmony account, and
"linkedinPassw0rd1" for your LinkedIn account.

At this point, I can't even tell if this is sarcasm.

~~~
mjschultz
It might help, but I think the cracking tools would simply get an update that
tries `password` and `<salt>password` (and even `password<salt>`).

As the salt is guessable (as it is in your examples) it just turns into a cat-
and-mouse game that the crackers win every time (since for every one of you
there are probably 2 or more of them).

~~~
AdamGibbins
One of the primary ideas behind salts is to render pre-generated rainbow
tables useless. Using a salt like the OP mentioned meets this need.

Although I'm unsure to how useful and widely used pre-generated rainbow tables
are with modern computing.

~~~
mjschultz
Well, in the eHarmony case we're talking about MD5 hashes, so even if you
self-salt the password but still choose a weak password a good password
cracker will find the password fairly quickly.

As an example, yesterday user rorrr posted this comment:
<https://news.ycombinator.com/item?id=4076840>.

> > MD5, SHA-1, SHA-256, SHA-512, et al, are not "password hashes." By all
> means use them for message authentication and integrity checking, but not
> for password authentication.

> Bullshit. MD5 is just fine, as long as you use the salt. Here, hack this:
    
    
        MD5(password + salt) = "b520542710812f347432232b2a1fba83"
        salt = "MD5 rules"
    

Self chosen salt, unknown password, known MD5 hashing method. Fire up a
password cracker and feed it in a decent dictionary, and you get the password
= "Spiderpig1".

    
    
        $ echo -n "Spiderpig1MD5 rules" | md5sum
        b520542710812f347432232b2a1fba83  -
    

No rainbow table needed.

~~~
AdamGibbins
Indeed, the hashing is useless so the salts are rendered ineffective. But
again, they're not 100% useless - they still do serve their purpose, to render
pre-generated tables useless. But when one can generate them again so quick it
provides negligible benefit.

------
diminoten
Is this newfound outpouring of confirmed hacks a result of the market becoming
more blasé about leaked passwords, or is this just a statistical anomale?

~~~
Mz
Eclipse? Transit of Venus?*

* (I know, I know: Wrong crowd. But take it as a tongue in cheek way of saying that it could be a "trend" with another explanation than either of the two you posit.)

~~~
diminoten
That's fair, I just wonder if there's some valid research worth doing here to
figure out what's going on. Hacks aren't exactly going down, after all, and if
we knew at least one of the causes that we don't already know about now,
security might be slightly easier.

~~~
Mz
If you are curious about what is behind the trend, you could start a file
collecting stories and see if you can spot any similarities, then ask around
or whatever (I am not a hacker, so not sure what the next research step would
be).

That is the kind of thing I do when something piques my curiosity and I want
it answered enough to satisfy my curiosity but don't care if it is answered
well enough to "prove" anything to anyone else.

------
ecaron
I have to imagine that this will open the potential for a viral website of the
"is your spouse still playing the field" variety.

------
5549900
Is it safe to let websites store personal information for you. Why not store
the information on your own storage media that you control with your own
hands? How long before Facebook is hacked? Would they even tell us about it
when it happens? The websites have not proven they can safeguard personal
information. Why should we keep giving it to them?

------
toyg
Any info on how these passwords were hashed? MD5, SHA*, salted, unsalted...?

~~~
jleader
The news articles I've read said SHA-1 for LinkedIn, and MD5 for eHarmony,
though I can't find the references right now.

------
debacle
What a strange week for security.

