Web Service Authentication Using PBKDF2 and a Public Salt - Does the salt need to change on every request?

Question

I have implemented PBKDF2 authentication for some web services.

The client is given the following information, so they can duplicate the PBKDF2 function:

• the hashing algorithm (SHA256)
• a secret password that is 30 bytes long
• the number of iterations (4096)
• the hash length (32)

The client is expected to generate a cryptographically secure random salt and use it in the PBKDF2 function. The resulting PBKDF2 hash and a base64 encoding of the salt is then added to an X-Authorization header in every request.

e.g. X-Authorization: 882fac38qkf98ff1ed29W4bd2f95P214=&&=2c55a195

All requests are done over https://. I have always been under the impression that a new salt should be generated on every request, as this prevents rainbow table attacks... but is this really necessary?

Let's say someone breaks through the TLS layer, and so they can see the password hash and the salt that was used. They are intent on breaking this password and so they create a rainbow table using this visible salt. I doubt they are going to crack a 30 byte password, but if they do, they now have the password we sent to the client.

At this point, with the password, they can make any request they like. It doesn't matter if a new salt is used on future requests. There is no need to create another rainbow table to crack those ones, because we already have the password.

Is there something I'm overlooking or misunderstanding? Is there a benefit to generating a new salt and running the PKDF2 function on every request?

Answer 1

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.

So, indeed using different salts for the same password is not helpful.

N.B.: If somebody can break TLS connections they will probably attack something more interesting than your webapp. ;)

Answer 2

Honestly? There is no need, its just extra processing overhead. If you create a unique salt, you can use it for all of your communications and the only way to break it would be the attacker got your salt, then used the salt to attack your password. If you used a complex password, little to 0 chance anything will happen.