EHarmony Confirms Password Hack
pcmag.com
pcmag.com
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.
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.
The solution to this, of course, is to make password security into its own industry, with its own principals who are incentivized to understand every facet of secure systems. 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.
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.
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?
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-github) products right now. Yet there's still a lot of services authenticating by `SELECT ... WHERE user='" + $user + "' AND pass='" + $pass + "'`.
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.
At this point, I can't even tell if this is sarcasm.
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).
Although I'm unsure to how useful and widely used pre-generated rainbow tables are with modern computing.
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).
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"
$ echo -n "Spiderpig1MD5 rules" | md5sum
b520542710812f347432232b2a1fba83 -
* (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 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.