Ignoring collision and (second) pre-image resistance, what makes a cryptographic hash function strong?

Question

With regards to resistance against dictionary and brute-force attacks to "crack" hashes containing passwords, what determines the resistance of a cryptographic hash function? Since collision resistance is not important for password storing, and, as far as I know, all the popular hash functions are resistant enough to pre-image and second pre-image attacks to make it an infeasible approach, I guess those factors don't really matter.

The first thing that crosses my mind is the amount of computation needed to calculate the hash (is there a word for this?) - the higher amount the longer it's going to take. Is there anything else? Bit-length? Is bit-length and "computation amount" somehow correlated?

Answer 1

Since the context of this appears to be password cracking, and cryptographic hashes are unsuitable for storing passwords, the simple answer is just "your question is irrelevant".

A good cryptographic hash function has a number of basic design goals:

• It should be computationally feasible to compute a hash H(x) for some input value x.
• Changing one bit of the input should change all output bits with a probability of 50%.
• Given only the hash output, it should not be computationally feasible to recover any information about the input (aside from generic attacks like rainbow tables).
• Given an input x₁, it should not be computationally feasible to find another input x₂ which satisfies the condition H(x₁) == H(x₂), i.e. it should be hard to find collisions.

While these basic goals are certainly useful, they don't really cover the full requirements of a good password storage function. To answer your question more specifically: large or controllable computational cost is most certainly not a feature of most "ordinary" cryptographic hash functions.

A good password storage function, alongside all of the above, should have these additional design goals:

• It should not be deterministic, i.e. two equal passwords for different users (or other entities) should not result in the same output hash.
• It should implement some form of defense against precomputation attacks (e.g. rainbow tables)
• It should be computationally expensive to brute-force the original input for all but trivial and common dictionary inputs. This is usually controlled by implementing a cost value, which allows for scaling of performance.
• There should not be a way to produce more than negligible performance gains using time/space tradeoffs.
• The performance of the function should be roughly linear across all architectures, to avoid acceleration by GPUs, FPGAs, etc. perhaps excluding specifically-designed silicon.

Some of these goals are similar to those implemented by key-derivation functions (KDFs) such as PBKDF2, but again these functions are not designed for password storage, and have instead been appropriated for such uses.

While there are currently only a few designs that implement all of the above, it is a relatively new field, so future works is expected. As a matter of interest, the current state-of-the-art for password storage, as per PHC, is Argon.