5 ms·

What is wrong with the above function? It's not obvious to me.

by mikek 14y ago

pjscott 14y ago
SHA256 is very fast, which makes it relatively easy to brute-force if someone gets their hands on your hashed password file.
- pbreit 14y ago
  Even with long, unique salts?
  - pjscott 14y ago
    Yes. A GPU can calculate more than two billion SHA-256 hashes per second, and adding 32 random bytes to each hashing is not going to slow it down enough to matter. Salting protects against rainbow tables; it's not an effective protection against someone just trying to brute-force guess passwords.
    - xvolter 14y ago
      This is true. The bruteforce attempts will include the salts in, simply adding to the length of the textdata being hashed. After they get the matching string to the hash, it's an easy enough process to then figure out which part is the password and which is the salt. Attempts to get around this are done by things such as: md5(sha1(md5(md5(password) + sha1(password)) + md5(password))) Which is not an appropriate method to circumvent. SHA512 is obviously a bit most costly, and therefore harder to bruteforce, but if you truly care about security you would be best to use PBKDF2 at minimum (built into Django's standard).
      - pjscott 14y ago
        I'm confused. That combination of SHA1 and MD5 is, itself, a hash function, and should be brute-forceable using the exact same methods you would use to brute force any other hash function. It's also easy to GPU-accelerate.
        ben0x539 14y ago
        I think the meaning was that combining SHA1 and MD5 is not an appropriate method to circumvent brute-forcing.
  - tptacek 14y ago
    Salts do absolutely nothing to make cracking take longer. The length of the salt might incur 1-2 additional calls to the SHA core permutation function, which is nothing.
richardv 14y ago
I believe that the original comment thought it was bad because the hashed password is stored alongside the salt. But, in practice this is never really a problem, because if they can get your hash, then the salt is usually always recoverable as well... This is where some people think they are being clever. Because they think to themselves, "hey, if I keep the salt secret and don't store the salt in the same table, or in the same field, then I've got awesome security by secrecy". So all they do is hard code a salt that they reuuse for every hash in their application. Which offers them a lot less security overall for their users. I have zero problem with storing the salt alongside the hashed password, because in practice, it doesn't make anything less secure.
- dchest 14y ago
  I have zero problem with storing the salt alongside the hashed password, because in practice, it doesn't make anything less secure. Great, now please go and fix your software to use slow password hashing function!
  - richardv 14y ago
    You quoted me totally out of context (I don't use SHA and you are implying that I do. I didn't spot that in your original paste snippet, and clearly wrongly assumed that you were just referring to the concatenation of hash to salt.) Nothing that I said was wrong (in fact it's sound advice), so I'm a little shocked at the massive downvotes, your blunt response, followed up with the patronising advice to rewrite all my software. (And no, I don't use SHA. I didn't spot that in your snippet.)
mjhall 14y ago
It's using sha256, which is far too fast. Key stretching is essential, especially when something as fast as a digest function like the SHA family is used. PBKDF2, as the article points out, can be used to increase the cost of brute forcing, but bcrypt should be considered before opting for PBKDF + SHA. An article [1] that appeared on HN last month (comments:[2]) also explains why just using hashing with a quick digest function is a bad idea, although this original article does a decent job of it (despite the author ignoring his/her own advice). This article also uses built in equality tests for comparing the supplied hash to the stored hash. This is bad practice, as it is vulnerable to timing attacks. [1] covers this in the Extra section. [1] : http://throwingfire.com/storing-passwords-securely/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+throwingfire+%28Throwing+Fire%29#notpasswordhashes http://throwingfire.com/storing-passwords-securely/?utm_sour... [2] : http://news.ycombinator.com/item?id=4075873 http://news.ycombinator.com/item?id=4075873
- gsf 14y ago
  "Key stretching is essential." Agreed. The article at http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/ is also convincing in this respect.

What is wrong with the above function? It's not obvious to me.

by mikek 14y ago

What is wrong with the above function? It's not obvious to me.

SHA256 is very fast, which makes it relatively easy to brute-force if someone gets their hands on your hashed password file.

pbreit 14y ago
Even with long, unique salts?
- pjscott 14y ago
  Yes. A GPU can calculate more than two billion SHA-256 hashes per second, and adding 32 random bytes to each hashing is not going to slow it down enough to matter. Salting protects against rainbow tables; it's not an effective protection against someone just trying to brute-force guess passwords.
  - xvolter 14y ago
    This is true. The bruteforce attempts will include the salts in, simply adding to the length of the textdata being hashed. After they get the matching string to the hash, it's an easy enough process to then figure out which part is the password and which is the salt. Attempts to get around this are done by things such as: md5(sha1(md5(md5(password) + sha1(password)) + md5(password))) Which is not an appropriate method to circumvent. SHA512 is obviously a bit most costly, and therefore harder to bruteforce, but if you truly care about security you would be best to use PBKDF2 at minimum (built into Django's standard).
    - pjscott 14y ago
      I'm confused. That combination of SHA1 and MD5 is, itself, a hash function, and should be brute-forceable using the exact same methods you would use to brute force any other hash function. It's also easy to GPU-accelerate.
      - ben0x539 14y ago
        I think the meaning was that combining SHA1 and MD5 is not an appropriate method to circumvent brute-forcing.
- tptacek 14y ago
  Salts do absolutely nothing to make cracking take longer. The length of the salt might incur 1-2 additional calls to the SHA core permutation function, which is nothing.

richardv 14y ago

I believe that the original comment thought it was bad because the hashed password is stored alongside the salt. But, in practice this is never really a problem, because if they can get your hash, then the salt is usually always recoverable as well... This is where some people think they are being clever. Because they think to themselves, "hey, if I keep the salt secret and don't store the salt in the same table, or in the same field, then I've got awesome security by secrecy". So all they do is hard code a salt that they reuuse for every hash in their application. Which offers them a lot less security overall for their users. I have zero problem with storing the salt alongside the hashed password, because in practice, it doesn't make anything less secure.

dchest 14y ago
I have zero problem with storing the salt alongside the hashed password, because in practice, it doesn't make anything less secure. Great, now please go and fix your software to use slow password hashing function!
- richardv 14y ago
  You quoted me totally out of context (I don't use SHA and you are implying that I do. I didn't spot that in your original paste snippet, and clearly wrongly assumed that you were just referring to the concatenation of hash to salt.) Nothing that I said was wrong (in fact it's sound advice), so I'm a little shocked at the massive downvotes, your blunt response, followed up with the patronising advice to rewrite all my software. (And no, I don't use SHA. I didn't spot that in your snippet.)

mjhall 14y ago

It's using sha256, which is far too fast. Key stretching is essential, especially when something as fast as a digest function like the SHA family is used. PBKDF2, as the article points out, can be used to increase the cost of brute forcing, but bcrypt should be considered before opting for PBKDF + SHA. An article [1] that appeared on HN last month (comments:[2]) also explains why just using hashing with a quick digest function is a bad idea, although this original article does a decent job of it (despite the author ignoring his/her own advice). This article also uses built in equality tests for comparing the supplied hash to the stored hash. This is bad practice, as it is vulnerable to timing attacks. [1] covers this in the Extra section. [1] : http://throwingfire.com/storing-passwords-securely/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+throwingfire+%28Throwing+Fire%29#notpasswordhashes http://throwingfire.com/storing-passwords-securely/?utm_sour... [2] : http://news.ycombinator.com/item?id=4075873 http://news.ycombinator.com/item?id=4075873

gsf 14y ago
"Key stretching is essential." Agreed. The article at http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/ is also convincing in this respect.