As of the next version of AoA's website I'm no longer going to store full-text passwords on my web server, instead, I'm going to hash them.

So, do you guys think that, 1.) I should make the password recoverable, or 2.) if not, what values, besides the hash, should I store in the database?

Thanks!

Do what I do.

- SHA hash the passwords in the database
- If the user forgot their password, reset it to a random six-digit number and email it to them.

[quote author=MyndFyre link=board=22;threadid=8739;start=0#msg80827 date=1095581935]
As of the next version of AoA's website I'm no longer going to store full-text passwords on my web server, instead, I'm going to hash them.

So, do you guys think that, 1.) I should make the password recoverable, or 2.) if not, what values, besides the hash, should I store in the database?

Thanks!
[/quote]

If you can make the password recoverable, then there is no point of hashing the password. Instead, do like st0rm mentioned, where you end up just resetting the password to a new pass. In the script, the logic would go: create a random number, compose an e-mail, send e-mail with random number to user, then hash number and update database with hash. For your user validation, you would just call hash on whatever the user input and compare it to the database value for that username. For user creation, you just take the text they entered and call hashing function and insert with the hash and not the text password. In theory, the users shouldn't be able to tell the difference from the old system and the new system. When you have it done, it'd probably be best to write a script that updates all the accounts with the new hashed form of their passwords.

[quote author=Magickian link=topic=8739.msg81898#msg81898 date=1096092730]
If you can make the password recoverable, then there is no point of hashing the password.[/quote]

I disagree; if you use a secret, strong private key, then you can maintain recoverable passwords whilst keeping your database secure, even if it is compromised.

By the way, my second question -- the only encryption I've ever used in my programming experience thus far has been MD5.  That requires an IV and a salt; that's why I was wondering what values I should store in the database.  ;)  As I've discovered, SHA1 does not require anything extra.

Not neccessarily, most MD5 implementations I've used only require one parameter. SHA-1 is much stronger than MD5 and is also 20 bytes instead of 16. You should never use MD5 unless interoperating with existing software.

[quote author=MyndFyre link=topic=8739.msg82655#msg82655 date=1096499207]
I disagree; if you use a secret, strong private key, then you can maintain recoverable passwords whilst keeping your database secure, even if it is compromised.
[/quote]
Hashing != Encrypting

[quote author=MyndFyre link=topic=8739.msg82655#msg82655 date=1096499207]
I disagree; if you use a secret, strong private key, then you can maintain recoverable passwords whilst keeping your database secure, even if it is compromised.
[/quote]
And how are you going to decrypt those passwords for password checks (for, say, logging on) if you are keeping the key in a safe place (i.e. not on the webserver/database server)...?

[quote author=Skywing link=topic=8739.msg82754#msg82754 date=1096572569]
[quote author=MyndFyre link=topic=8739.msg82655#msg82655 date=1096499207]
I disagree; if you use a secret, strong private key, then you can maintain recoverable passwords whilst keeping your database secure, even if it is compromised.
[/quote]
And how are you going to decrypt those passwords for password checks (for, say, logging on) if you are keeping the key in a safe place (i.e. not on the webserver/database server)...?
[/quote]

Exactly, so why not just check the hashed version of the password to [an] already stored hash of the existing password? I believe that's the way Battle.net does it, isn't it?

Edit: added fix between []