Is it okay to store salts with hashes?

Question

My understanding is that a salt is not intended to be secret, it is merely intended to be different from any centralized standard so that you can\'t develop a rainbow table or s

Answer 1

Using a single salt for all passwords in the database is helpful, but much less secure than giving each user a unique salt.

Basically: a longer (in bytes) password+salt increases the search space, and thus makes it harder to use "stock-standard" rainbow tables.

However, if the same salt is used for all entries, then it is possible to create a rainbow table specifically to attack your software. If your userbase is large then someone might decide to make such a rainbow table.

For example, if you simply add " and a lot of salt" to the end of each password before hashing, an attacker could construct a table of hash values generated by lots of strings, all those strings ending with " and a lot of salt".

For this reason, a per-user salt is the best way to go. However, remember that you also want the password+salt to be "long".

If you want to use the primary key, it's probably a good idea to take the hash of the primary key rather than using the primary key itself, because if the password+salt for user 43 looks like "myPassword00000000043" then an attacker could build a table with the assumption that there are a lot of zeroes in the middle. Creation timestamps and random string are probably better options though, as PKeys can sometimes be easily found or guessed.

Note: I'm not a true encryption expert, don't use this advice in a real system.