4 ms·

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 wa

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
    For web app passwords, brute force attacks against salted hash files are going to compromise so many passwords that the net effect to your business is going to be bad. With bcrypted or even PBKDF'd passwords, you'll at least have a plausible response to a compromise, and some certainty that hundreds of your users passwords aren't going to be posted to a web page.
    - thaumaturgy 17y ago
      Sorry, I still don't understand. Does this assume that all passwords share the same salt, so, not a nonce? Because if each hash has a nonce, I didn't know there was a fast way to brute force a database of those. (Assuming that the developer isn't using md5, of course, but even then I wouldn't expect it to yield a lot of results very quickly.)
      - tptacek 17y ago
        Sigh. 1. Take a hash. 2. Start at "aardvark". 3. SHA1 the salt + aadvark. 4. Compare to the hash. 5. Repeat until "zymoscope". It's so weird to me that rainbow tables have so captured people's imaginations that they can't comprehend other attacks to hashes, despite the fact that the brute-force attack I just described was the only way password files were ever cracked for the entirety of the 1990s. It's plenty fast.
        thaumaturgy 17y ago
        That attitude was uncalled-for. I'm aware of how brute force attacks work, thank you; and when you say "it's plenty fast", I'd guess you're referring to the difference between "slow" hashes -- like bcrypt -- or "fast" ones, like MD5. ...Which has nothing to do with whether salts are a good idea or not, which was actually my question. Furthermore, your example there assumes a dictionary to throw at the hashes, which is stupid, because if the website (or other application) doesn't have a sane password policy in the first place, then you don't even need their database of hashes. So, the whole "rainbow table" example you just sighed about was completely irrelevant to my question. Maybe I can put this another way that'll make more sense. Let's say I have a 150,000 computer botnet -- pretty small by today's standards, and not that hard to achieve really. And let's also say that I have a database of 10 million accounts that I snatched from some business, and better yet, let's say that they don't know about it, because I was uncommonly smart and I didn't brag that I got it. Now, I want to retrieve the passwords for as many of those 10 million accounts as possible, using my botnet. Further, let's say that the company was uncommonly smart, and they twofish'd all of their passwords with enough stretching to piss me off. How much more pissed-off will I be when I discover that they've concatenated a 128-bit randomly generated nonce to each password? Because my guess is, a lot more pissed off, since I can no longer distribute my dictionary of 500,000 commonly found passwords to the botnet, run it through their pessimal twofish, and then look for collisions.
swolchok 17y ago
> 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. And? Public key cryptography is impossible in an absolute sense, because there are algorithms that compute the private key given the public key. In fact, we have a good definition of "perfect secrecy", but the only cryptosystems that meet that definition must have keys that are as long as the message, which is impractical. Slowing the adversary down is how practical cryptography works.
- tptacek 17y ago
  It's a fallacy to compare the computational bounds of encryption algorithms to the human failures that break encryption systems.

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
  For web app passwords, brute force attacks against salted hash files are going to compromise so many passwords that the net effect to your business is going to be bad. With bcrypted or even PBKDF'd passwords, you'll at least have a plausible response to a compromise, and some certainty that hundreds of your users passwords aren't going to be posted to a web page.
  - thaumaturgy 17y ago
    Sorry, I still don't understand. Does this assume that all passwords share the same salt, so, not a nonce? Because if each hash has a nonce, I didn't know there was a fast way to brute force a database of those. (Assuming that the developer isn't using md5, of course, but even then I wouldn't expect it to yield a lot of results very quickly.)
    - tptacek 17y ago
      Sigh. 1. Take a hash. 2. Start at "aardvark". 3. SHA1 the salt + aadvark. 4. Compare to the hash. 5. Repeat until "zymoscope". It's so weird to me that rainbow tables have so captured people's imaginations that they can't comprehend other attacks to hashes, despite the fact that the brute-force attack I just described was the only way password files were ever cracked for the entirety of the 1990s. It's plenty fast.
      - thaumaturgy 17y ago
        That attitude was uncalled-for. I'm aware of how brute force attacks work, thank you; and when you say "it's plenty fast", I'd guess you're referring to the difference between "slow" hashes -- like bcrypt -- or "fast" ones, like MD5. ...Which has nothing to do with whether salts are a good idea or not, which was actually my question. Furthermore, your example there assumes a dictionary to throw at the hashes, which is stupid, because if the website (or other application) doesn't have a sane password policy in the first place, then you don't even need their database of hashes. So, the whole "rainbow table" example you just sighed about was completely irrelevant to my question. Maybe I can put this another way that'll make more sense. Let's say I have a 150,000 computer botnet -- pretty small by today's standards, and not that hard to achieve really. And let's also say that I have a database of 10 million accounts that I snatched from some business, and better yet, let's say that they don't know about it, because I was uncommonly smart and I didn't brag that I got it. Now, I want to retrieve the passwords for as many of those 10 million accounts as possible, using my botnet. Further, let's say that the company was uncommonly smart, and they twofish'd all of their passwords with enough stretching to piss me off. How much more pissed-off will I be when I discover that they've concatenated a 128-bit randomly generated nonce to each password? Because my guess is, a lot more pissed off, since I can no longer distribute my dictionary of 500,000 commonly found passwords to the botnet, run it through their pessimal twofish, and then look for collisions.

swolchok 17y ago

> 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. And? Public key cryptography is impossible in an absolute sense, because there are algorithms that compute the private key given the public key. In fact, we have a good definition of "perfect secrecy", but the only cryptosystems that meet that definition must have keys that are as long as the message, which is impractical. Slowing the adversary down is how practical cryptography works.

tptacek 17y ago
It's a fallacy to compare the computational bounds of encryption algorithms to the human failures that break encryption systems.