This is incorrect. If you are hashing passwords (or doing equivalent operations - specifically, the inputs are much lower entropy than the bit length of the ha

This is incorrect. If you are hashing passwords (or doing equivalent operations - specifically, the inputs are much lower entropy than the bit length of the hash output, and attackers have basically unlimited guesses), then you want a password-hashing algorithm, and not a general-purpose cryptographic hash, and you want it to be much, much slower than any general-purpose cryptographic hash - i.e., each attempt should take a good fraction of a second. Argon2 and scrypt are good password-hashing algorithms. None of MDx nor SHA-x nor BLAKEx are suitable here, at least not directly. (You can use them as a primitive in a password-hashing algorithm - for instance, Argon2 happens to use BLAKE2 internally - but then it doesn't matter if the primitive is "too fast," the password-hashing algorithm will just run it multiple times to slow things down.) For all other purposes, including signing and verifying files (documents, executables, etc.), signing and verifying cryptographic certificates, signing and verifying chats, etc., - i.e., cases where the input is higher entropy than the hash length and you're using the hash to allow you to sign/verify a smaller item than the original message - you want a fast, secure cryptographic hash, because that's how you build a fast, reliable system that people will use and not decide they want to use plaintext instead. Also, as it happens, most cryptographic hashes (not password-hashing algorithms) that are slow are also weaker than the cryptographic hashes that are fast. These are two different use cases that demand two different tools, and it's dangerous to lump them in under the terms "security context," because you'll end up with less secure and less usable systems. Password hashing needs a password hashing algorithm to be even slightly secure, and everything else needs a good hash, not just a slow one.