Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

EHarmony Confirms Password Hack

pcmag.com

Post reply on HN
Print view View original

21–30 of 33 posts

Re: EHarmony Confirms Password Hack

#21

Post by Mz »

diminoten wrote: post #19
Mz wrote: post #10

Earlier quoted context omitted.

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

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.

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.

Re: EHarmony Confirms Password Hack

#22

Post by seanp2k2 »

Lukeas14 wrote: post #3

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.

See also: VUPEN hack with 130 0-days supposedly leaked.

Re: EHarmony Confirms Password Hack

#23

Post by pbreit »

Lukeas14 wrote: post #17
stcredzero wrote: post #6

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 ciphe…

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 ch…

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

Re: EHarmony Confirms Password Hack

#24

Post by mjschultz »

AdamGibbins wrote: post #20
mjschultz wrote: post #18

Earlier quoted context omitted.

It might help, but I think the cracking tools would simply get an update that tries `password` and ` password` (and even `password `). 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).

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.

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.

Re: EHarmony Confirms Password Hack

#25

Post by AdamGibbins »

mjschultz wrote: post #24
AdamGibbins wrote: post #20

Earlier quoted context omitted.

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.

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 in…

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.

Re: EHarmony Confirms Password Hack

#26

Post by AncientPC »

AdamGibbins wrote: post #20
mjschultz wrote: post #18

Earlier quoted context omitted.

It might help, but I think the cracking tools would simply get an update that tries `password` and ` password` (and even `password `). 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).

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.

Self-salting with the domain name serves another purpose: prevents you from using the same password across multiple sites.

If your password is "password_linkedin", it's fairly obvious what the salt is. However, most released passwords are not heavily scrutinized. It's most likely that those using exposed passwords will instead try user@email.com / password_linkedin elsewhere.

You can also easily change self-salt so it doesn't fit any obvious pattern. What I do is a strong base password, then self-salt with the domain name. For example:

Mk3+e1_T2iei

I'm using "Mk3+e1_T" as the base password, "2" as a divider, and "iei" are the first 3 vowels of a domain name (LinkedIn in this example).

Re: EHarmony Confirms Password Hack

#27

Post by stcredzero »

derefr wrote: post #14
lawnchair_larry wrote: post #9

Earlier quoted context omitted.

I think if you care enough about password security to know these appliances exist, you already know how to use a proper password storage scheme. The ones that we are seeing dumped were not even trying.

What the parent is talking about is basically a solution to the http://en.wikipedia.org/wiki/Principal%E2%80%93agent_problem . I don't think these password compromises were likely failures of management to say "let's build a secure system"; they were failures of the engineers told to "build a secure system" to know and care enough about building secure systems to learn about things like bcrypt/scrypt in the first pla…

I don't think these password compromises were likely failures of management to say "let's build a secure system";...

The solution to this...would resolve as the parent explains--third-party vendors selling these companies multi-million-dollar "password appliances" with installation, support contracts, and all of that brouhaha--and then bringing in their support engineers to teach the company's own people how to securely call into the appliance.

Screw that. Just use a specific API in BSON structured with fixed-length fields to make the call. Build the appliance as proprietary software to install on top of an existing secure Linux distro. Sell to small sites for $1000 a pop or so, with different licensing for virtual server and cloud hosting companies. If Big Co. needs serious bandwidth, then they can do a project.

Hardware component: that we'd need VC funding for. Hardware is just harder.

Re: EHarmony Confirms Password Hack

#28

Post by stcredzero »

Lukeas14 wrote: post #17
stcredzero wrote: post #6

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 ciphe…

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 ch…

This would be a good selling point for companies once they have a little funding. Save yourself some embarrassment and plop down $1000 for a properly secured password db. There's also a strong selling point for the sites that have gotten hacked.

Re: EHarmony Confirms Password Hack

#29

Post by stcredzero »

viraptor wrote: post #12
stcredzero wrote: post #6

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 ciphe…

How many services use ldap with per-user controlled access, kerberos or radius for authenticating their users? Yeah... If we're not using what's available now, why would people start using specific appliances? I know the list here has a wide range of possibilities and doesn't map exactly to what you describe. What I mean is that we can do things 10 times better than we do them now with off-the-shelf (or even, off-the…

Yeah... If we're not using what's available now, why would people start using specific appliances?

Convenience? If it was possible to just plop down $1000, redirect some calls, setup a migration, and be done with it in an afternoon, more people would do it.

Re: EHarmony Confirms Password Hack

#30

Post by stcredzero »

eli wrote: post #7
stcredzero wrote: post #6

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 ciphe…

That seems like it would be just as much work (and just as prone to errors) as building it right in the first place.

Nah, you just a) have to make the call to an authentication function twice (first call sends the old hash hashed again into to the new system, then if that doesn't auth, call the old system), b) set up a migration that inserts the old password hashes into the new system. The new system hashes that data for you.
Post reply on HN