[akvadrako]

It doesn't matter if it's a "password hash" if it's a cryptographically secure hash and a long enough password. If it can withstand all the attacks that give you shortcuts to finding out what the input was, given the output, it's fine.

Password hashes only help protect against brute force searches by increasing the cost to attack linearly with the cost to verify. But that isn't a great tradeoff and isn't future-proof.

[fulafel]

All the crypto engineering that goes into password hashes is about the fact that passwords aren't long enough, so your "if" caveat makes your argument rather disconnected from the real world. People won't use passwords with the sufficient amount of entropy, they couldn't even if they wanted to (because of memorizing difficulties, typos, lack of good text entry UI on mobile devices, etc).

As long as you're using a password entry field designed for manual entry, you can't credibly counter that with "people should use password managers and autogenerated long line-noise passwords". Because you can't base your security upon all your users taking the initiative and doing the power-user non-default thing.

[akvadrako]

It's also true that even with a "password hash" your short password is not secure. It makes the attack more expensive, maybe from $10 to $10000 today, or $1000 next year. But practically that isn't something you should rely on.

[fulafel]

Now you flipped over to the other extreme :) I'll leave it to others to argue how there are parameters that make an acceptable tradeoff for proof-of-work hashes like scrypt for many applications.

[akvadrako]

I didn't flip - my point is "password hashes" and other secure hashes are similarly secure. You need a long password to trust it won't be brute-forced.