2

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]

Mike Ounsworth
  • 59,005
  • 21
  • 158
  • 212
  • There are a few existing questions: https://security.stackexchange.com/search?q=username+salt – PwdRsch Jan 31 '17 at 23:37
  • @PwdRsch Right. I swear I did that same search and didn't get anything on the first page. I'll flag my own question as a dupe when I get back to a computer. – Mike Ounsworth Jan 31 '17 at 23:45

1 Answers1

3
  • 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?
Luis Casillas
  • 10,681
  • 2
  • 30
  • 42