5 ms·

OK, so I get the message. Use bcrypt. Don't worry, that's what I'll do in production. On the other hand, if it's so hard to roll your own, can somebody point o

OK, so I get the message. Use bcrypt. Don't worry, that's what I'll do in production. On the other hand, if it's so hard to roll your own, can somebody point out the security flaws in the given Python function? Seems pretty straightforward to my untrained eye.

pmylund 14y ago
Although it's not that much if you're using a long hash, iterating a hash function causes you to lose entropy. The implementation in the article is basically PBKDF (1). PBKDF2/HMAC avoids this by making an "outer" and "inner" layer.
rmc 14y ago
The check of hash to input uses == which will shortcircuit and return quicker as you guess the leading digits allowing you to figure out what the hash is. (i.e. a timing attack)
- tptacek 14y ago
  Try to explain how you would actually conduct that timing attack to see why it isn't one.
  - indygreg2 14y ago
    If you are going to go through all the effort to do it properly, you might as well use a proper comparison function. If nothing else, it reinforces the knowledge that string comparisons can be part of security (which goes overlooked by many).
    - tptacek 14y ago
      The == operator is a proper string comparison function in this setting.
      - indygreg2 14y ago
        Assuming all the steps in the article are followed, yes, you are correct. I still think any article talking about verifying credentials is obligated to mention that string comparison could be an attack vector. Like I said, it plants a seed. And, I've seen way too many naive implementations where it is needed (like simple token-based auth systems) to know that this seed needs to be spread a lot more.
        tptacek 14y ago
        No, not assuming that. It has nothing to do with the specific steps. To see why, try to imagine a scenario where there could be an operator== timing attack on a password hash. It feels sometimes like people hear about the idea of timing attacks and then want to see them everywhere.
        tveita 14y ago
        > try to imagine a scenario where there could be an operator== timing attack on a password hash Sure, that's simple. You're leaking information about the password hash to the attacker, which they can use to speed up an attack where they have large offline resources but are limited in their online guessing capacity. Let's e.g. assume we have an unsalted hash, but the system limits us to one guess per second. The password is hashed, then compared with ==, taking some variable time we'll assume can be measured. We use an iterated timing attack to discover a prefix of the password hash, then run an offline dictionary or brute force attack using that prefix. Passwords that match the known part of the hash are tried online, potentially revealing more of the hash as we go. > It feels sometimes like people hear about the idea of timing attacks and then want to see them everywhere. When it comes to side channel attacks, "vulnerable" is the default state.
        pmylund 14y ago
        How does this matter given a proper avalanche effect?
    - pmylund 14y ago
      I'm not sure I agree that it would matter, but, either way, using a constant-time equality function might have given readers the impression that my code was safe to use. It isn't. That was never the intention. One of my main points was that it's extremely hard to do properly. My (pseudo-code) examples were intended to explain the concepts of salting and stretching. Perhaps it's unfortunate that they're actually valid Python. People should use proven KDFs for password authentication, not implement their own (including using my SHA-salting/iteration examples.) Edit: removed "in web apps"
      - tptacek 14y ago
        Many timing attacks are viable in web applications. But there aren't timing attacks against password hash comparisons, for obvious reasons.
        pmylund 14y ago
        You're right. That was an unfortunate choice of words.
  - fan 14y ago
    To the majority of users, including me, that idea is actually novel, and the novelty itself demonstrates the hidden corners that are lurking quite well. I believe that point was well made, even though in a technical sense, the exact error was unfounded.

pmylund 14y ago

Although it's not that much if you're using a long hash, iterating a hash function causes you to lose entropy. The implementation in the article is basically PBKDF (1). PBKDF2/HMAC avoids this by making an "outer" and "inner" layer.

rmc 14y ago

The check of hash to input uses == which will shortcircuit and return quicker as you guess the leading digits allowing you to figure out what the hash is. (i.e. a timing attack)

tptacek 14y ago
Try to explain how you would actually conduct that timing attack to see why it isn't one.
- indygreg2 14y ago
  If you are going to go through all the effort to do it properly, you might as well use a proper comparison function. If nothing else, it reinforces the knowledge that string comparisons can be part of security (which goes overlooked by many).
  - tptacek 14y ago
    The == operator is a proper string comparison function in this setting.
    - indygreg2 14y ago
      Assuming all the steps in the article are followed, yes, you are correct. I still think any article talking about verifying credentials is obligated to mention that string comparison could be an attack vector. Like I said, it plants a seed. And, I've seen way too many naive implementations where it is needed (like simple token-based auth systems) to know that this seed needs to be spread a lot more.
      - tptacek 14y ago
        No, not assuming that. It has nothing to do with the specific steps. To see why, try to imagine a scenario where there could be an operator== timing attack on a password hash. It feels sometimes like people hear about the idea of timing attacks and then want to see them everywhere.
        tveita 14y ago
        > try to imagine a scenario where there could be an operator== timing attack on a password hash Sure, that's simple. You're leaking information about the password hash to the attacker, which they can use to speed up an attack where they have large offline resources but are limited in their online guessing capacity. Let's e.g. assume we have an unsalted hash, but the system limits us to one guess per second. The password is hashed, then compared with ==, taking some variable time we'll assume can be measured. We use an iterated timing attack to discover a prefix of the password hash, then run an offline dictionary or brute force attack using that prefix. Passwords that match the known part of the hash are tried online, potentially revealing more of the hash as we go. > It feels sometimes like people hear about the idea of timing attacks and then want to see them everywhere. When it comes to side channel attacks, "vulnerable" is the default state.
        pmylund 14y ago
        How does this matter given a proper avalanche effect?
  - pmylund 14y ago
    I'm not sure I agree that it would matter, but, either way, using a constant-time equality function might have given readers the impression that my code was safe to use. It isn't. That was never the intention. One of my main points was that it's extremely hard to do properly. My (pseudo-code) examples were intended to explain the concepts of salting and stretching. Perhaps it's unfortunate that they're actually valid Python. People should use proven KDFs for password authentication, not implement their own (including using my SHA-salting/iteration examples.) Edit: removed "in web apps"
    - tptacek 14y ago
      Many timing attacks are viable in web applications. But there aren't timing attacks against password hash comparisons, for obvious reasons.
      - pmylund 14y ago
        You're right. That was an unfortunate choice of words.
- fan 14y ago
  To the majority of users, including me, that idea is actually novel, and the novelty itself demonstrates the hidden corners that are lurking quite well. I believe that point was well made, even though in a technical sense, the exact error was unfounded.