Security benefits from a second opinion, are there flaws in my plan to hash & salt user passwords via postgresql?

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 saved 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?

Well, I plan to store the email address the account is first created with as-is, unto perpetuity, but allow for a "active" account email to be added and changed by the user at will, so an administrator could simply change the "active" email address and not modify the "original" email address. I could just create a random, user-specific salt -from- the original email as an added layer, I suppose, thanks. That has the added benefit of obfuscating the email, I suppose.

Tchalvak 2010-04-14 20:14:36

As long as it's immutable once the account is created, and also difficult to guess. Using a random value or millisecond-precise timestamp is probably a little safer than deriving it from user data only because this is harder to guess. But your purpose would be served as long as you know you can always recreate the hash reliably for a given plaintext password.

MightyE 2010-04-14 20:39:35

ansaurus

tags:

views:

answers: