5 ms·

The broader take home message of the article: "Don't invent security protocols (e.g., involving hashing) as there can be surprising weaknesses. Find a well-desi

by imurray 17y ago

The broader take home message of the article: "Don't invent security protocols (e.g., involving hashing) as there can be surprising weaknesses. Find a well-designed library routine that already does what you want."

Locke1689 17y ago
"Don't do crypto yourself."
- deleted 17y ago
  [deleted]
arantius 17y ago
True, but I believe the point is still valid. Given knowledge of cryptographic hashes, and ignorance of HMAC, it is a perfectly reasonable assumption to use a hash in this way. I think that's a rather common situation, and outcome. And, blindingly obvious in hindsight (I have definitely heard of HMAC before, at least) but new to me too.
- tptacek 17y ago
  There is no generalist developer in the world that will come up with HMAC when given the "secure hash algorithm" tool and the knowledge that you can "sign" or "protect" a message concatenating it with a key. HMAC is surprisingly intricate. That there is no simple, intuitive alternative to HMAC is a strong reason not to allow developers to work at the "picking algorithms and constructions" level of cryptography. The rule is, "data in motion should be secured with TLS, data at rest should be secured with PGP". What worried me about posts like this is that they communicate the idea that, if you just know a couple more things (like, "HMAC"), you can get crypto right. No. For instance, this article doesn't explain how to safely compare HMACs. The intuitive way to compare securely is drastically insecure. The correct way to do it is surprisingly intricate. If you're typing the letters H-M-A-C into your code, you're doing it wrong.
  - ptoomey3 17y ago
    Not to mention, the article mentions using HMAC for his password databases. I am not sure how this is any better than salting. His argument against salting was that the salt is going to be stored somewhere. Well, the key he is going to use with HMAC is going to be stored somewhere too. In general, hashed password storage is a tough game to win in an absolute sense. So, we are effectively left with slowing the attacker down to the point that it isn't worth their while. I didn't see any mention of using iterative hashing (aka stretching) to increase the time required by an attacker to brute-force passwords. I agree with your "TLS in motion and PGP at rest" quote, though I don't know if we have a similar thing we can point to for password storage. Is there a go-to library we can just say "hey, use this". I know we can use bcrypt, or do iterative hashing, etc. But, I don't know off the top of my head what stock library we should tell folks to use so they minimize the chance of shooting themselves in the foot with password storage. Maybe this is something that should be added to keyczar.
    - tptacek 17y ago
      Salted hashes are not that much better than unsalted hashes, but HMAC itself isn't meaningfully different than just using a salted hash. You have to know the key to complete the hash, just like you have to know the salt in a salted scheme. You know you're getting into trouble with someone's understanding of systems security when you start talking about "secret salts".
      - thaumaturgy 17y ago
        > Salted hashes are not that much better than unsalted hashes... This statement made my eyebrows go up, and I pretty closely follow everything you say here on HN, and a lot of the things you say on Matasano. Are you saying "not much better" in the relative sense, as in, "not much better because if all you're doing is salting, then you're still doing it wrong"? Or more absolutely, as in, "salting doesn't gain you anything"?
        tptacek 17y ago

by imurray 17y ago

Locke1689 17y ago

"Don't do crypto yourself."

deleted 17y ago
[deleted]

arantius 17y ago

True, but I believe the point is still valid. Given knowledge of cryptographic hashes, and ignorance of HMAC, it is a perfectly reasonable assumption to use a hash in this way. I think that's a rather common situation, and outcome. And, blindingly obvious in hindsight (I have definitely heard of HMAC before, at least) but new to me too.

tptacek 17y ago
There is no generalist developer in the world that will come up with HMAC when given the "secure hash algorithm" tool and the knowledge that you can "sign" or "protect" a message concatenating it with a key. HMAC is surprisingly intricate. That there is no simple, intuitive alternative to HMAC is a strong reason not to allow developers to work at the "picking algorithms and constructions" level of cryptography. The rule is, "data in motion should be secured with TLS, data at rest should be secured with PGP". What worried me about posts like this is that they communicate the idea that, if you just know a couple more things (like, "HMAC"), you can get crypto right. No. For instance, this article doesn't explain how to safely compare HMACs. The intuitive way to compare securely is drastically insecure. The correct way to do it is surprisingly intricate. If you're typing the letters H-M-A-C into your code, you're doing it wrong.
- ptoomey3 17y ago
  Not to mention, the article mentions using HMAC for his password databases. I am not sure how this is any better than salting. His argument against salting was that the salt is going to be stored somewhere. Well, the key he is going to use with HMAC is going to be stored somewhere too. In general, hashed password storage is a tough game to win in an absolute sense. So, we are effectively left with slowing the attacker down to the point that it isn't worth their while. I didn't see any mention of using iterative hashing (aka stretching) to increase the time required by an attacker to brute-force passwords. I agree with your "TLS in motion and PGP at rest" quote, though I don't know if we have a similar thing we can point to for password storage. Is there a go-to library we can just say "hey, use this". I know we can use bcrypt, or do iterative hashing, etc. But, I don't know off the top of my head what stock library we should tell folks to use so they minimize the chance of shooting themselves in the foot with password storage. Maybe this is something that should be added to keyczar.
  - tptacek 17y ago
    Salted hashes are not that much better than unsalted hashes, but HMAC itself isn't meaningfully different than just using a salted hash. You have to know the key to complete the hash, just like you have to know the salt in a salted scheme. You know you're getting into trouble with someone's understanding of systems security when you start talking about "secret salts".
    - thaumaturgy 17y ago
      > Salted hashes are not that much better than unsalted hashes... This statement made my eyebrows go up, and I pretty closely follow everything you say here on HN, and a lot of the things you say on Matasano. Are you saying "not much better" in the relative sense, as in, "not much better because if all you're doing is salting, then you're still doing it wrong"? Or more absolutely, as in, "salting doesn't gain you anything"?
      - tptacek 17y ago