| Ideal salt is a large (e.g. 16 bytes or more) random byte string generated for each password. If there's a reason for it (in most cases, there is none), some trade offs are possible, e.g.: Salt is a large random string unique per user, not per password. Given two hashes of passwords for the same user it reveals whether passwords are the same. Salt is a small random string or some predictable value. Attackers can precompute guesses and then look them up. If you use some immutable identifier per user as salt, both of these attacks are possible. Is there a reason for this? Since you already store password hash in your database, I'm 100% certain that it's not, you can generate large random salt per each password hash and store it. As for "safe to make public": there are many things in crypto called "public" where "public" doesn't mean that the whole world is free to get it, but instead means an opposite of "private", or, as I like to call them, "non-secret". Yes, salt can be made public, but shouldn't (unless there's a reason for it — like in a kind of client-side crypto where server stores salt and sends it to clients) to avoid precomputation. |
Of course it's per user.
But "large" makes some sense. My current implementation has maybe 20-22 bits of uniqueness in the salt, certainly less than 16 bytes.
I don't think 16 bytes is necessary even as insurance against the future. Rainbow tables are still expensive to build.
On the other hand, maybe to build just a small table addressing the stupidest passwords ("password","12345678",etc.) it's worth making it more difficult.