Not at all true. There are many applications where a fast hash function is desirable and speed does not really impact its security. File integrity, for exampl

Not at all true. There are many applications where a fast hash function is desirable and speed does not really impact its security. File integrity, for example, is less of a burden to check with a fast hash and the attacks you'd mainly be worried about are some form of collision attack or second pre-image. For secure hash functions, the number of hash operations required to carry out the attack is so huge that the speed of the actual hash operation doesn't make much of a difference. Where people always seem to get this idea from is password storage. In that scenario, the attack is an attacker trying to brute force guess a secret input from the hashed output. Since passwords don't tend to be very good, the number of hash operations required in that attack is low enough that suddenly the speed of the hash function DOES impact how feasible the attack is. The solution to this problem isn't that all hash functions need to be slower, it's that people should stop using fast hash functions for password storage. Fortunately there are a number of ways to turn a fast hash function into a slow password storage function. Or you can use a function specially designed for password storage like bcrypt or scrypt.