6

I'm thinking of implementing a salt recycling scheme on my user credentials database. The motivation behind this decision is that even if the attacker manages to get his hands on the database and has enough time to crack a password or two, by the time he does the salt will have been reset and his results will be useless.

My current user registration code is the following (PHP-flavored pseudocode):

function getSalt($username){
    $salt=$username.getFromUrandom($SALT_RANDOM_READ); //64 bytes
    $salt=sha256($salt);
    return $salt;
}

function setPass($username, $salt, $pass){
    $pass=bcrypt($BCRYPT_WORK_FACTOR, $pass, $salt); //factor is set to 8 for now
    store_to_db($username, $pass);
}

setPass($username, getSalt($username), $plainpass);

What I propose to do is, instead of merely changing the factor to keep up with Moore's law, also change the salt every few days or so. Of course that would only benefit regular users who login every couple of days. In code:

if(today() - getLastLogin() > $SALT_CHANGE_THRESHOLD || /*work factor increased*/)
    setPass($username, getSalt($username), $plainpass); //as above

My questions:

  • How often should a salt change? I'm tempted to do it daily but I'm worried it might be a bit of an overkill
  • Is changing the salt enough to do without a password reset every couple of months? I won't be implementing that because I know users find it annoying, and it may force them to select a password they might later forget.

As I said above, non-returning users will not benefit from this. Users who use the same password with another compromised service will also not benefit but I'm not worried about that.

I'm also very tempted to use the most common passwords list and prevent users from selecting any of them in order to protect from using compromised passwords (although using all 10000 is a bit extreme).

1
  • 1
    64 byte salts are overkill. 16 bytes are enough. Using more doesn't gain you anything in practice. Jul 31, 2013 at 9:38

3 Answers 3

17

Your salt probably doesn't need to change any more often than your password. Rotating through salts doesn't protect you from anything in particular.

Note that the salt that the attacker uses to brute-force a password does not have to be the same as the salt in use when he uses the password. Only the password needs to be the same. And since the result of his attack is to determine the correct password, that password will continue to work no matter how often you rotate your salt.

5
  • I thought the point of the attack is to find a preimage? If the salt changes, the hash changes and so the preimage becomes useless. Am I missing something? I'm assuming the preimage found by the attacker is not the same as the password, of course.
    – rath
    Jul 31, 2013 at 3:44
  • 7
    Nope. Finding a collision is very nearly impossible. He instead tries plausible passwords and figures out if he guess correctly. If he hits a match, he can be nearly 100% certain that it's a match of the original correct password.
    – tylerl
    Jul 31, 2013 at 3:45
  • @rath It is very unlikely that someone will create a rainbow table with your salt in the first place. One unique salt per user would do the job, as the person would need to create a rainbow table for every single user to attempt to find the actual password.
    – Simon
    Jul 31, 2013 at 3:47
  • 1
    @rath If your hash function doesn't suck, then finding a pre-image that's not the original password is practically impossible. Even for mediocre hashes like MD5 there are no practical pre-image attacks. Jul 31, 2013 at 9:40
  • @rath The point of the attack is to find the password. That's indeed a preimage. The flaw in your reasoning is that if the salt changes, that does not make the hash invalid. The attacker can keep looking for a preimage for the old salted hash. But you've also given him an additional option to crack the new salted hash instead or in parallel. Jul 31, 2013 at 11:06
9

Never. Resetting the salt does not provide any security improvement. Your motivation is that ”even if the attacker manages to get his hands on the database and has enough time to crack a password or two, by the time he does the salt will have been reset and his results will be useless.“ But that's completely wrong! The attacker is trying to find the password. His results will be useful regardless of which salted hash of the same password he attacked. In terms of directly protecting the password or the access to the account, changing the salt is neutral, it has no impact on security.

Overall resetting the salt reduces security. Mainly, it reduces security because it adds complexity: it's a new source of potential bugs. Also it reduces security by making the attacker's job easier, although in a largely theoretical manner: if the attacker obtains multiple copies of the password database at different times, then he can get the same password with different salts. Taken to an extreme, the attacker can wait until he finds a salt that he's precomputed a rainbow table for. This isn't a practical concern because it takes exponential time to get a linear reduction in the effect of the salt (exposing 2n hashes with distinct salts is equivalent to making the salt n bits shorter). Nonetheless, you've decreased security.

Think of it this way: by hashing the password with multiple salts, you're exposing the password more. This goes against the goal of keeping the password secret.

Change the salt only when the password changes or when you increase the number of iterations on the password hash derivation function.

1
  • I remember a question on Crypto.SE that discussed the theoretical part of your answer, but I couldn't find it, glad you gave me the gist of it.
    – rath
    Jul 31, 2013 at 16:14
1

There are two possibilities -- either the attacker has found the actual password, or the attacker has found a hash collision.

In the former case, changing the salt is pointless, in the later case it might help. Whether it would help depends largely on whether they found the match by brute forcing the password (starting with "", and ending up with "password1") or whether they tried various known possibilities and found a match (ie started with "password" and ended with "password1"). If the later, then they almost certainly have the password, and not just a hash collision.

Also, remember that real security does not depend on the attacker being ignorant of your defenses -- if the attacker knows that you change the salt, then a failure gives him two avenues of attack for the same password. And with continual access, the more you change the salt the more information about the password you are giving the attacker.

You must log in to answer this question.

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