5 ms·

You must take the next paragraph into consideration: All major internet sites, anybody with more than 50.000 passwords, should design or configure a unique alg

• dchest 14y ago
  By combining two or more standard functions you're creating a different cryptographic primitive, which must be evaluated accordingly. For example (while collision resistance is not that important for password hashing), by chaining MD5(SHA1(x)) you've created a better chance of collision than if you just used SHA1(x). If you use 10 hash functions in any possible combination, you must evaluate the security of every possible combination, or prove that your resulting function is secure with any combination of these 10 functions. And for what? For only a slightly larger, constant, cost of attack, which you can easily get by adjusting a parameter in scrypt.
  • EthanHeilman 14y ago
    Not if you use a permutation like a block cipher with a fixed key, rather than an arbitrary function.
    • dchest 14y ago
      Not what? That you've suggested a completely different scheme (single algorithm with a key) to the one described in the comment I replied to (combining multiple algorithms)? :) (Note that even using a standard block cipher requires a separate evaluation for different purposes -- you can't claim that your hash function/MAC/mode of operation is as secure as AES only because it's based on AES.) If you read my replies in this thread, I emphasize the point that if you really need a custom function with secret parameters, use a single algorithm with a secret key (I even gave a link to one such scheme with HMAC.)
      • EthanHeilman 14y ago
        You missed my point. I was saying that this scheme AES(key, SHA256(password|salt)) is at least as secure as this scheme SHA256(password|salt).
        • marshray 14y ago
          No, it can be worse. If 'key' must be kept secret in order to achieve its stated security properties now the system is much more unwieldy for the defender. He now has a key distribution problem that he didn't have before. If the defender can reliably solve the key distribution problem then the attacker wouldn't have gotten a copy of the password key database. On the other hand, if 'key' is public, then the incremental computational cost added with AES raises the cost for the defender, but not the attacker. The attacker can just un-AES a password hash once and remember the result whereas the defender must perform the AES on every password validation.
          • EthanHeilman 14y ago
            Consider the possibilities: (1) if the key is captured by the attacker the system is just as strong as SHA256, (2) If the key is not captured by the attacker then the system is as unbreakable as AES. Many of the attacks that lead to password hash exposure involve a SQL injection that dumps the password table. If you store the password in the source code an attacker must then capture both the source code and the hashes. Furthermore, if they leak your key, you learn that they have gained access to your source code. I agree that this is a less than ideal system. My point was not to design a better system, but to point out that composing permutations with a secure hash function is at least as strong as that secure hash function. If you disagree consider the identity permutation. Really you'd want to implement it like SHA256(AES(key,SHA256(password|salt)). If I wanted to design a better system this is what I would do. Put the hashing system on a dedicated box that maps passwords to hashes. To compromise the hash key an attacker must compromise your hashing box and your database. Locking-down a box that performs only one action, hashing, is significantly easier than locking down a complex web application.
  • phkamp 14y ago
    Collision resitance is not really a worry for a password scrambler, until the probability gets into the 1e-6 range or above.
    • dchest 14y ago
      Yes, that's what I said in parentheses.