I have a unique identifiers that I would like to keep secure and provide information about it through tokens. These tokens should be verifiable after using the same algorithm on other end system with presented ID and comparing these values.

I am thinking to use PBKDF2 as a one-way function to get such tokens from IDs. But to be verifiable I should use the same SALT everywhere.

Are there any security issues related to use the same SALT in PBKDF2 for all IDs?

  • $\begingroup$ Based on your comments below on Maarten's answer, I'm fairly sure that PBKDF2 (alone) is not the right solution to your problem. Unfortunately, you have not clearly explained what your actual problem is, so it's hard to suggest any better solutions. At the very least, you might want to edit the extra information you've given in the comments below into your question. $\endgroup$ Commented Jul 8, 2016 at 23:15
  • $\begingroup$ crypto.stackexchange.com/questions/37592/… $\endgroup$ Commented Jul 9, 2016 at 5:00
  • $\begingroup$ ship the salt with the hash, no need to store it. many bcrypt outputs concat them up by default... $\endgroup$
    – dandavis
    Commented Jul 9, 2016 at 9:45
  • $\begingroup$ If I ship salt with hash, how would someone else verify token without knowledge of ID? $\endgroup$ Commented Jul 9, 2016 at 12:07

1 Answer 1


Are there any security issues related to use the same SALT in PBKDF2 for all IDs?

Yes, you can build a rainbow table or brute force the ID's.

An attacker could build up a table with tokens. Once the table exists the attacker can try all possible ID's until one of them matches. That way the function is reversible and your requirement to keep the ID secure has faltered.

Of course if the ID has enough entropy then the brute force attack will be impossible. But in that case you would not need the PBKDF2 function in the first place.

I don't see why you could not store a salt with a specific token by the way. Generally tokens are short lived.

Disclaimer: this is just a direct answer to the question, not a protocol analysis.

  • $\begingroup$ I am not able to store salt with specific token because token calculation takes place in two different places and comparison should be made. In that case I need to know salt in order to do PBKDF2 on specific ID..... $\endgroup$ Commented Jul 8, 2016 at 14:52
  • $\begingroup$ Why can you not make a comparison if you store the salt with the token? $\endgroup$
    – Maarten Bodewes
    Commented Jul 8, 2016 at 14:53
  • $\begingroup$ Because on one end point where I need to calculate token (I can't send ID through network) must be able to get the same value, which will be compared on second end point. I am not sending ID to second end point to calculate and compare. $\endgroup$ Commented Jul 8, 2016 at 14:55
  • $\begingroup$ But if you send the token you also send the salt right? If the salt is part of the token? $\endgroup$
    – Maarten Bodewes
    Commented Jul 8, 2016 at 14:58
  • $\begingroup$ No. One end point has stored token, without knowledge of ID. Second end point needs to calculate the same token from ID as input and send it to second end point for verification. If I send salt with token, second end point would not be able to do calculation with it because ID is not stored. $\endgroup$ Commented Jul 8, 2016 at 15:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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