I have what I think is a securely generated salt/hashing mechanism for HMAC authentication based on SHA256 in place. However, I'm using the salt in, from what I can see, a fairly standard way of just appending to the rest of the token before the hash generation like so;

// conceptual, not actual code...
var saltedToken = token + salt;
var hash = HashGenerator.Get(saltedToken);

But is appending the salt enough to be secure or should I be doing something more with it, e.g. applying the salt as an XOR operation on the rest of the token, etc. This answer implies that putting the salt at the start may be insecure in some hashing algorithms but I'm left unsure.

Is a straight forward "append salt" approach enough? Or do I need to scramble it further before hashing?

1 Answer 1


You do not need to salt in HMAC, per my best understanding. Salting prevents rainbow tables of common hashed things - in the case of passwords, this is because there are lots of people with the same password, way too often. In an HMAC algorithm, you are hashing a message and secret key, concatenated in a specific way. This is not something there will be a rainbow table for, so salting is not necessary. The answer you see has to do with password hashing, not HMAC.

https://www.rfc-editor.org/rfc/rfc2104 is probably how you want to do this - but really, implementing this sort of thing yourself is rarely what you want to do. Use libraries for cryptographic functions, choosing ones that have been studied and reviewed by cryptographers.

More detailed questions are probably best asked in crypto.stackexchange.com, rather than here

EDIT to clarify: Note that for a straight hash, you have HASH(message) - message has only one part. When you talk about prepending a salt, then it's HASH(CONCATENATE(hash,message)). When an RFC2104 HMAC is in place, you have HMAC(key, message). PBKDF2, defined in RFC2898 PKCS #5, uses HMAC with salt, message, where some additional math applies so that the output of the each HMAC iteration feeds into the next HMAC round.

  • I'm not sure I'm in full agreement here that the salt isn't required. In this instance, a salt would help against someone trying to brute force the key and assemble what's being hashed along with whatever key they're testing. My question centered around the need to increase the difficulty for the attacker by not applying the salt in an easily decypherable fashon (which appending is). As to the link, it's literally 20 years out of date and while a good base, is now somewhat suspect in its approach. And yes, I do use standard libraries for the hash generation but it's left up to us for hmac
    – DiskJunky
    Nov 1, 2017 at 14:51
  • 1
    In what way would it help? The salt is not unknown, it would have to be appended to the HMAC/message in some way (or it would simply be another secret key). Salts only help by preventing either a> rainbow tables, which are not relevant or b> being able to deduce two plaintexts are the same. I suppose that could be a concern, but generally in a HMAC signing situation, the attacker knows the valid plaintext, they are attempting to forge a signature on a plaintext of their choice. What attack are you expecting salt to solve?
    – crovers
    Nov 1, 2017 at 15:21
  • This is ultimately my understanding or lack thereof but is it not a possible source of attack to make construction of what gets hashed, easy? By applying the salt in a particular way, does this not make a forgery more difficult?
    – DiskJunky
    Nov 1, 2017 at 15:24
  • 1
    If you mean generating collisions, then I do not believe using a salt makes that any more difficult... Nov 1, 2017 at 15:32
  • 1
    I think a look over here would make things easier to understand. fr.wikipedia.org/wiki/Keyed-Hash_Message_Authentication_Code Take a look at this video too explaining very well the concept behind HMAC youtube.com/watch?v=wlSG3pEiQdc Jan 24, 2018 at 8:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .