4 ms·

> That's not how hash functions work... Kind of. A hash function just provides a near random set of characters of fixed length for a given set of input in a w

> That's not how hash functions work... Kind of. A hash function just provides a near random set of characters of fixed length for a given set of input in a way where the output characters are reproducible for the given input. Passwords are not stored. It is the computed hash value that is stored. When a user attempts to login with a username and password the password is hashed and compared to the stored hash. That said you don't need the actual password to login. Any input that hashes to the same hash string is acceptable, which is called a hash collision. When they say cracking the hash this is likely what they mean, and its trivial to compute provided a rainbow table. Salting provides an additional round of computation. For example let's say a user is trying to login. Their password is hashed but before the hashed are compared some additional information is added on the end of the computed hash and that new value is hashed. It is this new hash that is compared with the stored hash, which requires knowledge of the hash algorithm, the salt, and the hash value. You can generally guess the final hash algorithm in question by observing the character length of the stored hashes, but since there are two hash computations a different hash algorithm could be used for the first round of hashing. 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. Statically expressed passwords are uploaded to code repositories all the time. Don't believe that you are protected from associated vulnerabilities merely because the code base isn't open source. To the article's defense neither claim was verified, but both claims were reported. When the journalist cannot validate a claim themselves, or with experts, it is completely acceptable to report the claim and report the validation status.

dgzl 8y ago
> To the article's defense neither claim was verified, but both claims were reported. When the journalist cannot validate a claim themselves, or with experts, it is completely acceptable to report the claim and report the validation status. The reporter says they successfully produced passwords, sounds clean-cut and dry to me. Don't you think this is a pretty important claim to verify, instead of asserting without giving proof? Granted, if a dictionary attack gives you a bunch of 'password' variants, you probably don't need much more evidence. If the reporter is so invested in producing this story, then being able to say "no, these are definitely passwords" in the face of the executive would be the golden ticket, right?
Novashi 8y ago
>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 is outdated though. You don't need to take extra steps to secure the salt if you move to a good hash.
- RJIb8RBYxzAMX9u 8y ago
  "Hashing" is unfortunately a very overloaded term. Even searching for "password hashing" gave me pretty bad results for the top hits. "Key derivation function" (KDF) gave much better results.
throwawaymath 8y ago
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).

dgzl 8y ago

> To the article's defense neither claim was verified, but both claims were reported. When the journalist cannot validate a claim themselves, or with experts, it is completely acceptable to report the claim and report the validation status. The reporter says they successfully produced passwords, sounds clean-cut and dry to me. Don't you think this is a pretty important claim to verify, instead of asserting without giving proof? Granted, if a dictionary attack gives you a bunch of 'password' variants, you probably don't need much more evidence. If the reporter is so invested in producing this story, then being able to say "no, these are definitely passwords" in the face of the executive would be the golden ticket, right?

Novashi 8y ago

>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 is outdated though. You don't need to take extra steps to secure the salt if you move to a good hash.

RJIb8RBYxzAMX9u 8y ago
"Hashing" is unfortunately a very overloaded term. Even searching for "password hashing" gave me pretty bad results for the top hits. "Key derivation function" (KDF) gave much better results.

throwawaymath 8y ago

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).