2

Right now I have a "salt" column and a "password" column in the database (the user table), both varchar(64) and take sha-256 hashes as values.

Do you think it's a good idea to eliminate the salt column and use the user's e-mail address to generate a salt during password validation? This would save some space in the database.

JohnSmith
  • 239
  • 2
  • 5

3 Answers3

5

I don't think it's a problem to store the a random salt, instead of deriving them from other columns of the user.

However, if you decide to use one or more other columns for the salt, you need to be 100% sure that the value chosen never changes. In your example, if the user changes email address, you have lost any way to validate his password.

driis
  • 161,458
  • 45
  • 265
  • 341
  • But how would that happen if the salt is generated on each login attempt based on the current email address in the db? -- Ah I understand now :) – JohnSmith Dec 10 '11 at 21:24
  • @JohnSmith, what driis is saying is that, if the salt is generated from the email column, and the salt is applied to the password and the email is then changed, the password is now not going to match. – Moo-Juice Dec 10 '11 at 21:27
  • What if I used the user ID (the primary key) ? That's guaranteed to never change. – JohnSmith Dec 10 '11 at 21:28
  • 1
    Using the ID would be OK. One could argue that the salt then is somewhat predictable, but due to the way hashing works, I don't think this is a security problem. – driis Dec 10 '11 at 21:49
2

A salt should never, ever change. An Email address can. Your thinking of the removal of the salt column is the DBA equivalent of premature optimization, with the added consequence of disastrous results.

Moo-Juice
  • 38,257
  • 10
  • 78
  • 128
2

See this answer for why you should use a random salt for every password creation.

Community
  • 1
  • 1
Christian Semrau
  • 8,913
  • 2
  • 32
  • 39