This question already has an answer here:

The point of salting your password hashes is to prevent the attacker from using an off-the-shelf rainbow table. The salt needs to be unique per user, but doesn't need to be secret.

Why not use the username / user ID as a salt rather than staring a separate value in the DB. Is there some reason you'd need to change a user's salt in the future?

[I would have expected to find a question like this already, but I didn't. I also didn't look very hard]

marked as duplicate by PwdRsch, AviD Feb 1 '17 at 0:06

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • The fact that the salt is a deterministic function of the username makes it likely that users who use the same username and password on two different sites might end up with the same password hash on both. Attackers who observe this coincidence might then focus their efforts on cracking those password entries, so you might be exposing your users to more risk. (This could in principle be mitigated by incorporating some site-specific data to the salt.)
  • When the user changes their password, it would be salted identically to the previous one. Crackers can then attack those two password entries with the same effort as just one.
  • It just doesn't really gain you anything compared to the simple expedient of selecting a random salt each time you store a new password. This is simple and optimal, because random salts are not just highly likely to be unique within your database, but also across all password databases ever kept. Why deviate from a strategy that's both simple and optimal?

Not the answer you're looking for? Browse other questions tagged or ask your own question.