Safe to create the hash and salt inside a database trigger?

Question

I'm wondering which system should generate the hash and salt for a secure webapplication.

There are 3 possibilities in my setup :

• (Javascript) client
• PHP server
• MySQL server

At this moment I've implemented it in the MySQL-server inside a trigger. What it does is take the unhashed/uncrypted password in a field called 'PasswordHash' when a new user is created, so the original password is in the INSERT statement.

But in the INSERT Before trigger this password is hashed (SHA1) with a random salt (UUID) that is concatenated with the hash into a variable @hashandsalt. (I already found out it's not really a good idea to store the hash and salt into separate columns).

Then I do SET NEW.PasswordHash = @hashandsalt; so the original password is never written to the database, but replaced with the hash+salt.

Is this a good idea?

I can see a problem with the logging of MySQL, because all logged INSERT-statements of the users-table contain the original passwords then. I don't use default MySQL logging at this moment, but I'm not really sure how MySQL stores all incoming statements internally.

What would be the best option to generate the hash and salt in your opinion?

Answer 1

The best way would be to use a PHP function that hashes the password for you.

If you have PHP =>5.5.0 then you can use the Password extension. It handles everything for you so that you do not have to think about it. Unless you are an expert in the field thinking too much about it is, quite frankly, not a very good idea.

$password = filter_input(INPUT_POST, 'password', FILTER_UNSAFE_RAW);
$hashed = password_hash($password, PASSWORD_BCRYPT);
// Done!

If you have PHP <5.5.0 then there are several options, among them:

1. Use the compatibility library by mr. Anthony Ferrara.
2. Use another library (PHPass for example).
3. Use the crypt() function (it is slightly bothersome to use, but works fine)

As for Javascript, no. Just, no. Password hashing should be invisible to the client, and should never leave the internal network.

Doing it in SQL may work, but I do not think it is such a good idea, especially if you have written it yourself. No offence, but writing your own hashing algorithms is rarely a good idea; you should use algorithms written by people who know what they are doing, and which have been peer-reviewed by other experts.