I am trying to define algorithm that would create a irreversible token from IDs, which are 10 digit information, and then would be compared on two different end points.

Between end points, only sending tokens is allowed, no IDs can be send from one end point to another. End points are not sharing any secret information like cryptographic keys.

The situation will be that server would have database with stored tokens, not IDs. When end point would like to verify ID, it will calculate token from ID using the same algorithm and send it to server to match. It should not be feasible for attacker to get ID back from token.

I was thinking about using SHA-512 but it seems to be not very secure as, for example using hashcat, I am able to create all hashes of 10 digits IDs very fast.

If I use PBKDF2 with number of rounds to slow down the attack I would need to use the same salt for every end point as they need it to calculate token, which defeats the purpose. (PBKDF2 with the same salt for all IDs)

HMAC would probably be a good solution but it need to have symmetric key distributed among all end points that would like to calculate tokens, and I can't do that.

What algorithm would be the right for such solution if any? Is it even possible to achieve my goal without using shared secret?


Token should be then used as a unique ID so I assume that it should be calculated deterministically.

  • $\begingroup$ Using "the same salt for every end point" does not defeat the purpose of slowness; it only makes the salt much less useful. ​ However, see this question. ​ ​ ​ ​ $\endgroup$
    – user991
    Commented Jul 9, 2016 at 5:20
  • $\begingroup$ I think it is different because I need to calculate the same value on both end points in order to check it. Server has token and I need to check if token calculated on end point is actually stored on server. If the values would be different I would need to do 1:N matching. $\endgroup$ Commented Jul 9, 2016 at 6:39
  • $\begingroup$ In that case I can use HMAC but I don't want to distribute shared secret. $\endgroup$ Commented Jul 9, 2016 at 12:04
  • $\begingroup$ If I understand you correctly, you basically have users that want to authenticate themselves to multiple independent "end points" using a 10-digit numeric password ("ID"). The "end points" don't store any user data themselves, but rather consult a shared authentication server. The authentication server should not store (or, ideally, ever see) the passwords ("IDs") themselves, nor anything from which they could be derived. Some of the "end points" might be compromised, so they cannot securely store shared secret keys. Is that correct? $\endgroup$ Commented Jul 9, 2016 at 13:00
  • $\begingroup$ Yes, basically yes. $\endgroup$ Commented Jul 9, 2016 at 13:43


Your Answer

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