1

I have set it up so that when my users change their password, the salt is recomputed.

Besides hiding the fact that they may change their password to the same thing (I am checking that by first hashing their new pwd with the old salt) it doesn't really fulfill any purpose - or am I mistaken?

This answer states that:

The point of using salt is to prevent brute force attacks against multiple passwords at once. If they all have different salts your dictionary or rainbow table is only valid for one specific salt.

Which indicates that changing the salt has no impact...

Is there another hidden benefit, or am I over-complicating my password storage?

JoSSte
  • 149
  • 10

1 Answers1

2

If many passwords are hashed using the same salt, then at some point, it may become feasible for an attacker to compute a rainbow table of passwords hashed using this salt. This is the reason why a different randomly generated salt is used for each hashed password.

In your case, it seems unlikely that you would have enough passwords hashed with the same salt (even if the attacker was able to access users' history of changed passwords) to make it worthwhile for an attacker to compute a rainbow table of passwords hashed using this salt. But, as @Steffen Ullrich pointed out in the comments - there is no downside to using a new randomly generated salt each time the user changes their password, and nobody could argue that this is the wrong way to do it.

mti2935
  • 23,468
  • 2
  • 53
  • 73
  • Not quite -- https://crypto.stackexchange.com/a/18964/79037 – ManRow Jul 07 '23 at 14:13
  • @ManRow The answer that you linked seems to recommend using a different salt each time a new password is hashed - i.e. 'If the salt is not changed, any work the attacker has done may still be applicable to the new password'. Do you read it differently? – mti2935 Jul 14 '23 at 10:46
  • Not quite -- the purpose of my linked answer was to reply to your claim that "...In your case, it seems unlikely that you would have enough passwords hashed with the same salt (even if the attacker was able to access users' history of changed passwords) to make it worthwhile for an attacker to compute a rainbow table of passwords hashed using this salt..." – ManRow Jul 14 '23 at 17:52
  • The reason I put out the link is to emphasize what your answer seems to skip over -- the issue of "future passwords" (regarding OP's password resets). If an attacker, in an clandestine manner, is able to "view" the password database, then -- by not having salts rotated/changed on password resets -- they may easily crack any (human/low-entropy) future password by any given user as well. – ManRow Jul 14 '23 at 17:52
  • For example, they may create a rainbow table for a given user (or multiple tables for multiple users), and if the password salt never changes anyway, then any future (human/low-entropy) password (e.g, from password resets) from that user(s) could again be cracked by reusing the same already-computed rainbow table(s) from before. – ManRow Jul 14 '23 at 18:02
  • Yes, I agree. This is another reason to create a new random salt, each time a password is changed. – mti2935 Jul 14 '23 at 18:26