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?

3

1 Answer 1

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.

6
  • Not quite -- crypto.stackexchange.com/a/18964/79037
    – ManRow
    Commented Jul 7, 2023 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
    Commented Jul 14, 2023 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
    Commented Jul 14, 2023 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
    Commented Jul 14, 2023 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
    Commented Jul 14, 2023 at 18:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .