0
$\begingroup$

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?

Improve this question
$\endgroup$
4
  • $\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$
    – Ilmari Karonen
    Jul 8, 2016 at 23:15
  • $\begingroup$ crypto.stackexchange.com/questions/37592/… $\endgroup$
    – user1563721
    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
    Jul 9, 2016 at 9:45
  • $\begingroup$ If I ship salt with hash, how would someone else verify token without knowledge of ID? $\endgroup$
    – user1563721
    Jul 9, 2016 at 12:07

1 Answer 1

Reset to default
3
$\begingroup$

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.

Improve this answer
$\endgroup$
8
  • $\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$
    – user1563721
    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 ♦
    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$
    – user1563721
    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 ♦
    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$
    – user1563721
    Jul 8, 2016 at 15:02

Your Answer

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

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