Salted Hashes and Password Stories

Question

I wonder if it matters if the salt is unique to one given user each time the password is changed or if reuse of the same salt every time is of little importance.

I am currently generating a new random string as salt every time this user updates the password. Thus, every time a user has a new password, it is also a salt change. This is easy to do, so why not.

Well ... that’s why. I need to save previous X passwords so that the password is not reused. In the old days (the last time I wrote the code for this), I could just save the previous MD5 hashes and compare the new ones with this list. Well, now that I use salted hashes where the salt is unique every time, these comparisons are no longer possible, since the previous salts are no longer known.

To make this system work, I have two options: save the salt history in addition to the final hashes or reuse one salt for any given user with each password update. Any of them will allow me to create values ​​that can be compared with history.

The latter is less work, but will it lose power? From a practical point of view, I do not see that this is so. Thought I'd get a second opinion here. Thanks.

So that the question is “accountable” - reusing the same salt for any one user has an acceptable minimal reduction in protection in order to maintain a searchable password history (to prevent pswd processing)?

Answer 1

Reusing the same salt means that if the user is clearly targeted by the hacker, they can create a dictionary of "password to hash" using the "user salt" - so even if the user changes his password, the hacker will still immediately recognize the new password no extra work.

I will use different salts every time.

As for storing the MD5 hash plus salt - presumably you already store the salt + hash to check the current user password. Why can't you just keep the same information for historical checks? Thus, you can use one piece of code to verify the password, and not to separate the current and historical paths. They do the same, so it makes sense to use the same code.

EDIT: To explain what I mean, consider a 4-character salt added to the password ... and for the sake of argument, imagine that someone uses only AZ, az and 0-9 in their password (and salt).

If you do not know the salt ahead of time (when preparing a dictionary attack), then in order to prepare a dictionary for all 8-character "human" passwords, you need to use hashed 62 ^ 12 concatenated passwords. If, however, you always know what the first 4 characters of a concatenated password will be (because you know the salt ahead of time), then you can only get away with hashing 62 ^ 8 values ​​- everything that starts with salt. This makes salt useless against this particular attack.

This only works with the target user - and only if the attacker can get into the hash list both before and after changing the password. This basically makes password changes less effective as a security measure.

Answer 2

Another reason for using salt in password hashes is to hide the fact that two users use the same password (which is not unusual). Using different hashes, an attacker will not see this.

Answer 3

First, stop using MD5 (if you use it), and use SHA-2, MD5, SHA-0, and SHA-1, all dead hashes.

- Change:

Now I agree with John Skeet and suggest you think about creating a new salt every time you change your password. It covers a small case where an attacker can get a salt + hash, and then cannot access again, but still allow it (with some guesses about how you combine them) to calculate what hashes might be for all future passwords . This is very small, and it is not so important, because the size of passwords should be significantly small (for example, 8 characters) in order to even calculate them offline in practice. Nevertheless, it exists.

Secondly, to consider whether this is important, we need to think about the purpose of the salts. It is designed to prevent offline attacks against someone who has a complete list of only passwords.

On this basis, if salt is also "difficult" to obtain before and after changing the password, I do not see any new salt (it is just as dangerous as before). This adds extra complexity, and when implementing complexity, most security problems arise.

Answer 4

I could be incredibly lackluster here, but wherever you store salt that would not be accessible to someone with sufficient access to get a hashed password.