1

I'd like to build an authentication system, where each user has her own salt - each password gets hashed with the salt of the user it belongs to.

How should I design the database schema?

Here's a design I came up with, but I'm not sure about it, as hash depends on salt and this violates third normal form:

users(id, salt, hash, ...)
Emanuil Rusev
  • 34,563
  • 55
  • 137
  • 201
  • 2
    Just use bcrypt, no additional salt column required :) – Ja͢ck Oct 15 '12 at 10:55
  • @eggyal, including `salt` into the PK would not normalize the database as other possible attributes of users (such as email, first_name, etc.) would not depend on it. – Emanuil Rusev Oct 15 '12 at 11:17
  • @eggyal The bcrypt hash uses a salt upon generation as well as a cost factor (which makes it scale with hardware performance) and the result contains enough information to verify a password afterwards; and strictly speaking, a salt doesn't have to be unique, just a long enough random string is enough (22 chars for bcrypt). – Ja͢ck Oct 15 '12 at 11:44
  • @eggyal The salt, cost factor, algorithm, hash and salt are all part of the result of the `crypt()` call; it's therefore not the smallest of all hash results (64 chars I believe) but it certainly is (arguably) the strongest (if applied well). – Ja͢ck Oct 15 '12 at 11:51
  • @eggyal To illustrate my point, see my earlier answer on a related topic; you can skip the encryption portion; http://stackoverflow.com/questions/10916284/how-to-encrypt-decrypt-data-in-php/10945097#10945097 – Ja͢ck Oct 15 '12 at 11:58
  • @Jack: My apologies. I've learnt something new! – eggyal Oct 15 '12 at 12:10
  • @eggyal No worries, Bcrypt evangelisation yields another soul :) – Ja͢ck Oct 15 '12 at 12:16

2 Answers2

1

While I'm not a stickler for conformance to normalisation rules I understand where you're coming from.

To remove the offending column and yet retain its function you could consider simply concatenation the salt and the hash inside one field; you don't need a delimiter if one or both values keep the same length.

Alternatively, you can use Bcrypt as your password hash: the hashing takes a random salt together with the password and a cost factor; it produces a long string that you can store in the password field. Check out ircmaxell's blog for his work on this subject.

Ja͢ck
  • 170,779
  • 38
  • 263
  • 309
0

Your design is fine. Plenty of systems use this idea. It doesn't fully break 3NF as Hash is not strictly dependent (so to speak) on the salt, it was just computed from it (along with the password).

MatthewMcGovern
  • 3,466
  • 1
  • 19
  • 19