I am working on a personal project to build a REST authentication system which authenticate clients via three parameters:

apikey = example-apikey-34433
hash = examplehash-notarealhash-a34io4oehosseesr
timestamp = 2000000000

Every client has a unique apikey and secret key, stored in a database.

Hash is a SHA256 hash of the secret key + timestamp. This is to generate a unique authentication hash for every request.

Would this be secure against brute forcing? Because when a client can supply any timestamp, is it true that multiple hashes can be correct?

Wouldn't it be better to just rely on the apikey and (plain text) secret key? Or do you know a better way to do this?

  • 1
    $\begingroup$ You should also be aware of replay attacks. $\endgroup$
    – aventurin
    Commented Aug 9, 2016 at 11:15

1 Answer 1


Might need some clarification, but it sounds like you are wondering how to 'salt' the hash. First if you intend to concatenate the secret key with anything else, the standard way to handle this is a HMAC. A common way to handle this is PBKDF2:


Basically this does a secure combination of secret codes and the timestamp/salt. While the user can supply the timestamp, the probability that they could guess a timestamp that gives the same hash is very unlikely.

So PBKDF2 with a timestamp salt may be what you're looking for. Good Luck!

  • 1
    $\begingroup$ If the secret key is really a key, there is no need for a password-based hash. Instead a MAC would be the way to go and HMAC a good suggestion. $\endgroup$
    – otus
    Commented Feb 11, 2016 at 7:09
  • $\begingroup$ suppose that's true, but pbkdf could be helpful if you want to make bruteforcing harder, not that you'd really need it with SHA256. $\endgroup$
    – Azarinak
    Commented Feb 11, 2016 at 7:25
  • 1
    $\begingroup$ It's not about the hash function, but the key. A random key that's e.g. 128 bits simply cannot be brute forced. $\endgroup$
    – otus
    Commented Feb 11, 2016 at 7:47

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.