1

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?

  • 1
    "The client is given the following information" sounds a bit dangerous. How exactly is it given to him? – Elias Mar 14 '18 at 9:57
  • It is encrypted and send to the client using a secure, file sharing app that we control. – Sno Mar 14 '18 at 17:50
3

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. ;)

  • I see, thank you! Yea, I didn't realize the salt is there to prevent attacks on multiple passwords, and so it doesn't help in this use case. The point of the question was I just want to make sure I am doing things properly, not on the likelyhood that someone would attack me. – Sno Mar 14 '18 at 17:44
0

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.

  • Ok, I see, thank you! I thought this might be the case, but I wasn't sure if I was missing something. – Sno Mar 14 '18 at 17:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.