Add footnote warning to hashing a hash #411
Conversation
There was a problem hiding this comment.
While doing it over sha256 is obviously not as bad as doing it over md5
Sure it is. “Hash shucking” remains an issue, and the differences in collision resistance and output size aren’t relevant to this application.
How about recommending pre-hashing with HMAC as a keyed hash instead? Or just bcrypt.kdf?
You're absolutely right!
I've removed the mention of the DDoS attack, replaced I don't have a lot of experience with |
|
https://flak.tedunangst.com/post/new-openssh-key-format-and-bcrypt-pbkdf has some information about choosing parameters for bcrypt_pbkdf. I've fixed CircleCI so if you push a new commit here CI should pass now and we can get it reviewed 😄 |
README.rst
Outdated
| >>> password = b"an incredibly long password" * 10 | ||
| >>> hashed = bcrypt.hashpw( | ||
| ... base64.b64encode(hashlib.sha256(password).digest()), | ||
| ... base64.b64encode(bcrypt.kdf(password=password, |
There was a problem hiding this comment.
Ah, I meant using bcrypt.kdf directly instead of bcrypt.hashpw. This works, but it… feels unusual? If people want to keep the descriptive hash format that hashpw creates, HMAC seems simpler (although I guess the only concrete difference is that you don’t have to make an arbitrary choice for the number of output bytes and rounds).
There was a problem hiding this comment.
I see what you mean. I just literally placed one in the other, but there's more intuitive ways of doing this.
Do you mean base64.b64encode(bcrypt.kdf(password=password, salt=bcrypt.gensalt(), <whatever>))? Would password verification simply be to repeat the procedure and compare strings, or is there an analogue to hashpw?
And with the HMAC one, do you mean bcrypt.hashpw(base64.b64encode(hmac.digest(pepper, password, "sha256")), bcrypt.gensalt())?
If so, I suppose another important difference is that the latter requires storing a pepper (or per-hash salt) separately.
There was a problem hiding this comment.
I had forgotten about this PR, but it's now almost a year old. Luckily(?) the relevant section in the README has not been updated, so the changes here are still relevant.
Do you perhaps have time to take a look at my question to see if I understood your suggestion correctly?
There was a problem hiding this comment.
Do you mean
base64.b64encode(bcrypt.kdf(password=password, salt=bcrypt.gensalt(), <whatever>))? Would password verification simply be to repeat the procedure and compare strings, or is there an analogue tohashpw?And with the HMAC one, do you mean
bcrypt.hashpw(base64.b64encode(hmac.digest(pepper, password, "sha256")), bcrypt.gensalt())?
Yes and yes.
On second thought, though… maybe the best answer is replacing the code with your original footnote, and pointing back to “but you should really use argon2id” at the top of the README?
There was a problem hiding this comment.
lol, good point. I've made sure to emphasise that not using bcrypt is probably the best solution. However, I'm sure there will be people who will somehow be forced to use bcrypt, either because of legacy software, weird interoperability, legal requirements, incompetent management, you name it. So I think it is still worthwhile to explain how to work around the length limitation. I've also chosen to use the HMAC variant because if a reader doesn't already know about hash shucking and peppers, I think it's unlikely they'll manage to choose reasonable numbers of rounds and bytes.
Let me know what you think of the rewritten section.
|
closing/reopening to trigger CI |
It's generally not recommended to use bcrypt on top of another hashing algorithm. While doing it over sha256 is obviously not as bad as doing it over md5, I think it's important to note in the README that OWASP recommends against the practice.