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
  • 2
    $\begingroup$ A related question Why is H(k∥x) not a secure MAC construction?. Since you are not interested in a forgery or length extension attack, both should be fine for you. $\endgroup$ Commented Apr 14, 2020 at 16:52

1 Answer 1

Reset to default
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$ Commented Apr 14, 2020 at 19:34
  • $\begingroup$ @fgrieu once can use SHA256/224 or SHA512/256 etc. to mitigate from length extension attacks. $\endgroup$ Commented Apr 14, 2020 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$ Commented Apr 14, 2020 at 20:39

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.