0

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?

user1563721
  • 563
  • 4
  • 16
  • 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. – Ilmari Karonen Jul 08 '16 at 23:15
  • http://crypto.stackexchange.com/questions/37592/secure-algorithm-for-calculating-token-and-comparison – user1563721 Jul 09 '16 at 05:00
  • ship the salt with the hash, no need to store it. many bcrypt outputs concat them up by default... – dandavis Jul 09 '16 at 09:45
  • If I ship salt with hash, how would someone else verify token without knowledge of ID? – user1563721 Jul 09 '16 at 12:07

1 Answers1

3

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.

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
  • 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..... – user1563721 Jul 08 '16 at 14:52
  • Why can you not make a comparison if you store the salt with the token? – Maarten Bodewes Jul 08 '16 at 14:53
  • 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. – user1563721 Jul 08 '16 at 14:55
  • But if you send the token you also send the salt right? If the salt is part of the token? – Maarten Bodewes Jul 08 '16 at 14:58
  • 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. – user1563721 Jul 08 '16 at 15:02
  • That's worse as the "end point" without the ID would be the attacker. – Maarten Bodewes Jul 08 '16 at 15:07
  • Understand. Maybe the HMAC would be only way to go...but I wanted to avoid distribution of keys. – user1563721 Jul 08 '16 at 15:12
  • how does one build a rainbow table of PBKDF2 ? i thought PBKDF2 took a long time to run, and that rainbow tables need a lot of runs... – dandavis Jul 08 '16 at 18:07