using sha256 as hashing and salting with user's ID

Question

I'm gonna use sha256 for my site,to secure my users passwords,and as salt i was thinking of usings the users id (int auto_increment). that will be unique but not very long and hard,and public(user.php?id=1) but it just matters if its unique right?

hash('sha256', $id . $password);

molf · Accepted Answer · 2010-01-11T21:36:26.373

9

Yes, it is important that the salt is unique (collissions sufficiently unlikely), but it should also have enough entropy (be random and long enough). User ids are not random and may be too short, so your best bet is to use randomly generated strings and store them in your database alongside the hash.

Suppose a user with UID 9 chooses a stupid password: password. The resulting string that will be hashed may then be 9password. You can imagine that even in this case, the full string may appear in rainbow tables (tables which contain lots and lots of hashes with their original string).

If the salt in this case would be, for example, OTAzMzYzODQzMjk5NTM1NDc1N, the string to be hashed is OTAzMzYzODQzMjk5NTM1NDc1Npassword, which is a lot more unlikely to appear in rainbow tables. Also, the input strings are a lot longer, reducing the risk of brute force attacks.

edited Jan 11 '10 at 21:36

answered Jan 11 '10 at 18:32

molf

68,548
13
132
117

1

"Also, the hash strings are a lot longer". I'm pretty sure sha256 creates a 32 byte string regardless of the number of input characters. – rick Jan 11 '10 at 21:04
@rick, sorry for not being clear. I meant the input strings are longer. – molf Jan 11 '10 at 21:37
It is not so important that the salt is unique. The purpose of the salt is to protect simple passwords. This can be achieved even if all passwords in a system are salted with the same value. It is more important that the salt is a random value and has enough characters. – deamon Jan 11 '10 at 21:41
@deamon, if the salt is not unique your password hashes leak information, because different users with the same password (and same salt) will also have the same password hash. Not good. Collisions are no disaster, but it's a risk to use a system-wide "salt". – molf Jan 11 '10 at 21:45
To increase entropy, would it make sense to hash the salt and password individually and then hash the hashes? Then a secure salt could be generated from intuitive pieces of data such as UID. – Rupert Madden-Abbott May 23 '10 at 13:56
1

@Rupert, hashing does not increase entropy. – molf May 23 '10 at 15:27
+1 to molf. You cannot create more entropy from less entropy, just as you cannot create matter from nothing. – ʇsәɹoɈ Jun 12 '10 at 19:21
In this case, with only one system-wide salt, two users with the same password will not have the same hash - as long as you include the user ID as well: ($id.$password.$salt) – GC. Sep 16 '10 at 10:52

score 2 · Answer 2 · answered Jan 11 '10 at 18:37

This would work but the purpose of using salt is to differentiate the hash key to strengthen the crypt algorithm. It would be much better to use a unique, random generated / time salted string for salt. Also it would be better not to include the salt and hash key in the same table.

score 0 · Answer 3 · answered Jan 11 '10 at 18:37

0

Your salt should not be easily guessable. In one of it's more basic forms, you could simply create a salt based on the current TIMESTAMP using

   date('U')

which is far more secure due to its length, uniqueness, and the fact that you store it in the DB and don't make it publicly available. You would then utilize it in such a manner:

$hash = date('U');
$pass = hash('sha256', $hash . $password);

and as far as checking passwords on login:

// return query object based on matching email/username
if ($userobj->pass === hash('sha256', $userobj->salt .$_POST['pass'])) {
    // correct pass
}

answered Jan 11 '10 at 18:37

Corey Ballou

39,300
8
60
75

Salting your database isn't meant to make the password more secret, it's supposed to stop a hacker that has obtained your hashed password from being able to use a rainbow table to hack the hash. Even if he has the salt and password hash, it's still very difficult to get the password. – Ian Jan 11 '10 at 19:23
@Ian - And to prove my own point, wouldn't obscuring the password hash with a salt be accomplishing just that? Making the password more secret? – Corey Ballou Jan 11 '10 at 20:38
@Ian - with the salt a rainbow table can be created providing the attacker guesses the encryption algorithm and how the salt is appended to the password. If the original password is weak, it will be uncovered. – rick Jan 11 '10 at 21:56
Another benefit of this method is that the date is know in advance before the INSERT of the user (as opposed to auto-incremented id). This way you can do the hash server side at the same time as you create the user. This is good since you usually cant do sha256 in sql and don't want to roundtrip to the server again risking a user without any password! – aero Aug 19 '11 at 13:42

score 0 · Answer 4 · answered Jan 11 '10 at 18:39

I don't think that is a good choice: I would use a more random salt saving it into the user record. Maybe saving in the password field this string: sha256($password . $randomSalt) . '$' . $randomSalt

This way you can then retrieve the salt to check the passoword on login.

(Anyway you can also use another field for the salt alone)

using sha256 as hashing and salting with user's ID

4 Answers4

Linked