We will be taking steps to further protect our users starting with the elimination of all unnecessary information that has been optional, including birthdates, gender, city/state, etc. We will only be keeping alias, email, country and password. We will also look at further securing the passwords beyond what we do today.
What is a concern is if you use the same username/password, as so many do, then yes that is something you need to take upon yourself to better ensure your own information security.
More and more sites are getting hacked and you can't expect every website to do everything right, so a practice of using spamfilter garbage email addresses, keeping personal data private, and using strong and unique passwords for every account are what you can do to help ensure your own personal security.
That being said I think cheat happens already has the infrastructure in place to make their passwords NSA proof as well as recoverable.
The best practice is to either send a new and unique temporary password or a password reset link to the email address of the account. Cheathappens already does this, they just send you your current password instead of a garblygoop temporary one.
They also send you a reminder that you changed your password with an email which contains your new password. This just isn't necessary.
Also about the encryption as opposed to 1-way hashing. When a password table is compromised it should be assumed that the encryption key and algorithm are as well. If the encryption key could be ensured to remain a secret security experts wouldn't be so insistent on 1-way hashing.
But anyways, rock solid nsa-proof password security is actually pretty simple.
1) Add an 8 character varchar field to the user table, name is PasswordSalt, this value isn't a secret you can give it out to everybody. Salt ideally is unique for each user but random is good enough. For each user get 16 byte salt, encode to an 8 character base64 string.
2) Choose a KDF (key derivation function, not a hash algorithm). PBKDF2, BCrypt, and SCrypt are all excellent.
In terms of computational cost, SCrypt > BCrypt > PBKDF2
In terms of reputable time tested, PBKDF2 > BCrypt > SCrypt
3) Store the output of KDF(PasswordSalt + CleartextPassword) in the Password field.
4) When a user logs in, take the cleartext password they submitted to the server, and compare the output of
KDF(StoredPasswordSalt + SubmittedCleartextPassword)
to the StoredPassword value.
Thats it. A salted KDF is so expensive to bruteforce and make a rainbow table for, that the only passwords that could be found out are those that are extremely weak.
While I won't say that this is absolutely necessary, since I use unique passwords, I would be rather upset if my account were stolen. I rather like cheathappens.
So why implement a salted KDF?
1) Its easy.
2) Imagine successfully hacking a website's user table only to discover that it'll take you a second per guess per user? Thats a **** sandwich. You get satisfaction and peace of mind that anyone that hacks your site will be eating a **** sandwich.
3) You can brag to your patrons about how ridiculously secure you are. And feel pride for if ever your site gets hacked, probably nobody's password will be compromised. Good feels all around. Except for the hacker whos eating the **** sandwich.