Earlier quoted context omitted.
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 co…
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.
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}^*
H: {0, 1}^* -> {0, 1}^n.