Security benefits from a second opinion, are there flaws in my plan to hash & salt user passwords vi
- by Tchalvak
Here is my plan, and goals:
Overall Goals:
Security with a certain amount of simplicity & database-to-database transferrability, 'cause I'm no expert and could mess it up and I don't want to have to ask a lot of users to reset their passwords.
Easy to wipe the passwords for publishing a "wiped" databased of test data. (e.g. I'd like to be able to use a postgresql statement to simply reset all passwords to something simple so that testers can use that testing data for themselves).
Plan:
Hashing the passwords
Account creation records the original email that an account is created with, forever.
A global salt is used, e.g. "90fb16b6901dfceb73781ba4d8585f0503ac9391".
An account specific salt, the original email the account was created with, is used, e.g. "[email protected]".
The users's password is used, e.g. "password123" (I'll be warning against weak passwords in the signup form)
The combination of the global salt, account specific salt, and password is hashed via some hashing method in postgresql (haven't been able to find documentation for hashing functions in postgresql, but being able to use sha-2 or something like that would be nice if I could find it).
The hash gets stored in the database.
Recovering an account
To change their password, they have to go through standard password reset (and that reset email gets sent to the original email as well as the most recent account email that they have set).
Flaws?
Are there any flaws with this that I need to address? And are there best practices to doing hashing fully within postgresql?
