Tips for usersFirst of all, if there's only a single lesson that any user should take from all this mess it's this: never use the same password on two websites. If one of those websites is compromised your account on the other will easily be broken into as well.
Of course it's not very easy to remember a lot of passwords. You can either use a password locker like 1Password or divide websites into classes where you have different passwords for "important" websites like Google, your bank, Facebook, etc and then share a password on less important websites like forums you rarely visit. The former is of course more secure but it makes it a lot harder for you to quickly log into websites from a new computer.
Incompetent developers are dangerousNow, when we've covered good password policy for users it's time to move over to the actual website operators responsibility. How can eHarmony talk about "robust security measures". First of all they did not salt their passwords. If you do not salt the passwords when you hash them you are doing the equivalent of putting duct tape around the door instead of locking it. With rainbow tables it's extremely easy to crack non-salted password hashes.
I would also want to know why eHarmony considers a load balancer a robust security measure. It's very apparent that these engineers are not very knowledgeable when it comes to Internet security.
But salting password hashes is not enough. One needs to use a strong hashing algorithm. eHarmony used MD5 which is old and dated. LinkedIn used SHA1 which is more secure. But even if you use a good algorithm and salt the hashes there's still room for improvement.
We take security seriouslyAs I've discussed before our upcoming account system uses a number of measures to further increase security. First of all we hash the passwords before they are sent to the server using the SHA256 algorithm and salting with the user's email. When the hashed password reaches the server it is again hashed using the SHA1 algorithm. This time we salt both with a random string which we store in the database but also with a random string which is stored outside the database. The reason we use a salt stored outside the database is because most password leaks only involve the attacker gaining access to the database, not the file system.
Furthermore the server side hashing is done several time over, not just once. This will increase the time it will take to crack the passwords by several orders of magnitude. Rendering virtually impossible to crack them.
Using all these things is not very hard. It takes less than a day to implement and should be considered common sense when it comes to security practices. Apparently there's lot of million and billion dollar companies out there that don't have the skill to properly secure their systems. Heck, Sony even stored their passwords and credit card numbers in plain text. That's beyond incompetent, that's dangerous!
But it can get even betterAs a last note I want to mention two-factor authentication. Usually you need access to something you know in order to login to a website: your password. To get into your car or house you need something you have such as a key. Security measures could also include something you are (fingerprint, voice, retina scan). Two-factor authentication means you need two of these things. For example ATMs use two-factor auth since they both require something you have (card) and something you know (pin).
Website can use two-factor auth by requiring a password (something you know) and access to your cellphone (something you have) by sending you an SMS with a code to enter everytime you log into your account from a new computer. I would love to do this at Stoffi but sending text messages isn't free so for now we'll have to skip that. However, I recommend everyone to use it where it's possible, for example Facebook and Google.