2
$\begingroup$

Assume you are already given a properly-salted, password hash $X$ from some slow PBKDF (e.g., like Argon2id).

Now, you want to apply some large (~256-bit) secret "pepper" $S$ to it before storing it in the database.

Is there a significant difference between storing it as an $$\text{HMAC}\left(S,X\right)$$ (where $S$ is the secret key to the HMAC of $X$) versus a "much simpler/basic" $$H\left(S\mathbin\parallel X\right)$$

where $H$ is just some SHA-2? (e.g., SHA-256/512)

Improve this question
$\endgroup$
1
3
$\begingroup$

No for this scenario where the message is statically sized, using a HMAC is not required. You can use a sufficiently strong hash such as SHA-2 or SHA-3 instead if you must.

That said, it would probably be more neat to use a HMAC or even KDF. The advantage is that these algorithms do take input keying material as a separate parameter. This might be interesting if you want to keep the pepper secret; you could store it in a hardware device and use it for HMAC, for instance.

Currently you are using the hash as poor-man's KDF. So if you can spare a few cycles you might go for a more luxurious option like HKDF (which is based on HMAC).

Improve this answer
$\endgroup$
3
  • 1
    $\begingroup$ I agree with the conclusion, but not with "statically sized" as the sole argument (I get it as: length extension does not apply). It is necessary to invoke that SHA-2 is a good enough hash that $X\mapsto H(S\mathbin\parallel X)$ is a good PRF keyed by $S$ for constant-size $X$. It would be possible to define a weak $H$ such that observing $X\mapsto H(S\mathbin\parallel X)$ leaks $S$, when that would not apply to $\text{HMAC-H}(S,X)$. That is, not using HMAC puts unduly pressure on the hash, and that pressure is not part of its explicit design criteria. HMAC is advisable for unspecified $H$. $\endgroup$ – fgrieu♦ Apr 14 '20 at 19:34
  • $\begingroup$ @fgrieu once can use SHA256/224 or SHA512/256 etc. to mitigate from length extension attacks. $\endgroup$ – kelalaka Apr 14 '20 at 20:21
  • 2
    $\begingroup$ @fgrieu Sure, I put in a stronger hash requirement. You're theoretically correct of course, but the hash needs to be really weak for short, static, random content to become a problem in this scenario. $\endgroup$ – Maarten Bodewes♦ Apr 14 '20 at 20:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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