4 ms·

It's cool that you jumped on the opportunity to explain how password hashing works. However, the reporter actually cracked hashes, so we can bypass all of this

It's cool that you jumped on the opportunity to explain how password hashing works. However, the reporter actually cracked hashes, so we can bypass all of this discussion and plainly see the hashes were insecure. And for what it's worth: > To be secure the salt must be stored in a different location from the stored hashes and the salt value should not be statically visible in the source code provided a source code compromise. This isn't true. Your salt can be totally public if you're using a robust key derivation function. Likewise you can make e.g. the work factor (rounds) public for bcrypt and N, r and p public for scrypt (cost factor, block size and parallelization parameters). The rest of what you said about secrets management in code is sound though.

austincheney 8y ago
You cannot crack a hash though. It is just a string of fixed length. Nobody says crack a string because it sounds ridiculous. > Your salt can be totally public if you're using a robust key derivation function. That is a deliberate strawman. If your salt is based on keys there is still information you aren't exposing even if you are exposing the salt itself.
- deleted 8y ago
  [deleted]
- throwawaymath 8y ago
  Uh, what? You can obviously crack a hash digest, and this is standard nomenclature used in both industry and academia. It simply means you've broken preimage resistance or collision resistance in practice. What exactly do you find controversial about this? And your second paragraph doesn't follow. What I said isn't a strawman attack, it's a basic observation. If you're not using a secure key derivation function, a private salt will not save you. If you are, the salt can be public and there is no meaningful degradation in security whatsoever - you could even prepend or append it to the digest if you'd like. As a broader point, what you're saying about fixed-length strings is incorrect. Hash functions need not output strings of fixed length. The formal definition of a hash function also admits functions of the form: H: {0, 1}^* -> {0, 1}^* not just functions of the form: H: {0, 1}^* -> {0, 1}^n. Or in other words, the codomain need not be finite, and the range can be variable. Keccak (SHA-3) is an example of a hash function which provides variable-length output instead of fixed-length output (i.e. via the sponge construction).

austincheney 8y ago

You cannot crack a hash though. It is just a string of fixed length. Nobody says crack a string because it sounds ridiculous. > Your salt can be totally public if you're using a robust key derivation function. That is a deliberate strawman. If your salt is based on keys there is still information you aren't exposing even if you are exposing the salt itself.

deleted 8y ago
[deleted]
throwawaymath 8y ago
Uh, what? You can obviously crack a hash digest, and this is standard nomenclature used in both industry and academia. It simply means you've broken preimage resistance or collision resistance in practice. What exactly do you find controversial about this? And your second paragraph doesn't follow. What I said isn't a strawman attack, it's a basic observation. If you're not using a secure key derivation function, a private salt will not save you. If you are, the salt can be public and there is no meaningful degradation in security whatsoever - you could even prepend or append it to the digest if you'd like. As a broader point, what you're saying about fixed-length strings is incorrect. Hash functions need not output strings of fixed length. The formal definition of a hash function also admits functions of the form: H: {0, 1}^* -> {0, 1}^* not just functions of the form: H: {0, 1}^* -> {0, 1}^n. Or in other words, the codomain need not be finite, and the range can be variable. Keccak (SHA-3) is an example of a hash function which provides variable-length output instead of fixed-length output (i.e. via the sponge construction).