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

31–33 of 33 posts

Re: EHarmony Confirms Password Hack

#31

Post by lawnchair_larry »

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…

My position is that the engineers were probably told to "build a system". It's still uncommon for security to even be a thought, sadly.

Re: EHarmony Confirms Password Hack

#32

Post by jleader »

pbreit wrote: post #23
Lukeas14 wrote: post #17

Earlier quoted context omitted.

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.

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?

Post reply on HN