If hashes cannot be decrypted, then what is the point of using stronger hashes? Since are only uncrackable via brute force through hashing the text and comparing the hashed password, won't it be cracked in the same amount of time, no matter what hash you're using?
Cryptographic hashes do not exist in an independent world. They have actual use cases and for most of these use cases it is not important that a hash cannot be decrypted. But it is important that one cannot construct two inputs with the same hash (collision) or a different input for an existing hash (preimage attack). A very important use case is for example the use of cryptographic signatures as proof of a (trusted) origin when digitally signing documents, certificates, programs ... .
For example a preimage attack would allow to create a faked document, certificate or program which is different to the original one but as much trusted as the original one since the signature still matches. In these cases stronger hashes provide better protection against collision and preimage attacks.
Your assumption that "hashes cannot be decrypted" doesn't cover all possible attacks.
The most common use case for hashes is to hash two documents then compare the hashes. The assumption is that if two hash values are the same, then the original documents must also be the same.
Web site builders use this all the time to store password hashes instead of passwords. When a user logs in, their password is hashed and the value compared to what's stored in the database.
So let's look at a simplified example. Instead of SHA-256 or SHA-512, I'll create a hash algorithm using only addition of each letter. Hashing a password of "HELLO" works like this: H=8, E=5, L=12, L=12, O=15, so the hash is 8+5+12+12+15= 52. 52 goes in the database. 52 doesn't reveal my password, so it's secure, right?
But the only thing a user needs to login to my account is to enter a password whose letters sum up to 52. An attacker can use a pre-image attack to find an equivalent password. Trying all one letter passwords yields, nothing, but when I try all two letter passwords, I hit upon ZZ (Z=26, 26+26= 52). Because I matched the stored value, I was able to log in using the password ZZ.
A similar thing can happen when forging a document that is signed with a hash. Your boss may compute the hash on a document saying "increase TheDomesticUser's pay by twenty", then digitally signs the hash so HR knows it came from your boss. With this weak algorithm, it's trivial to change the document to "increase TheDomesticUser's pay by forty" and add some extra letters to the end until the hash matches the original value.
What I'm trying to do with these contrived examples is to demonstrate that hash algorithms have to have enough strength to prevent these kinds of attacks. Some are definitely "weaker" than others. Attacks on more complex hash algorithms, such as RC4, MD5, and SHA-1, have enabled attackers to forge web server certificates, allowing them to intercept communications. By forging a code signing certificate, attackers have been able to sign malware such that they can distribute viruses.
It's important that only secure hash algorithms are used, and that as weaknesses are found in algorithms that they be replaced.
The password cracking attacks that you allude to rest on one key practical assumption:
- ASSUMPTION: The cost of guessing lots and lots of likely inputs is practical.
Passwords as a general rule satisfy that assumption, but there's lots of other types of data that doesn't. If I take a photo out my window right now and I give you the SHA-256 hash (
6c97d8bb820e3125ea85c9d6de757e49ce8e4970a40fc6ecce2a489ed1858b59), for example, there's no practical way for you to reconstruct the exact input file, or even for you to tell if I'm actually lying and it's just the output of
openssl rand -hex 32 (i.e., 32 random bytes).
But note that the inability to work backwards to the input (technically known as preimage resistance) isn't the only property a cryptographic hash function is supposed to provide. Another important property, called collision resistance is that you shouldn't be able to find any two strings (of your choice!) that hash to the same output. The problem with MD5 and SHA-1 isn't just that their outputs are too short; it's that practical algorithms exist that can find pairs of inputs that produce the same output, and that have been leveraged to demonstrate practical attacks on Internet security. That's why cryptographers insist that we all use SHA-2 or some other newer function that they are confident about.
Note that in the case of passwords, you are actually right that using SHA-512 instead of MD5 doesn't really help because the cost of making a ton of likely guesses is practical in both cases and isn't much different between them. But hashing passwords with MD5 or SHA-512 is a bad practice, and rather you're supposed to hash them with specialized password hashing functions like Argon2 that are designed to make password cracking costly. The "strength" that these functions are designed to provide isn't the same as the "strength" of a bigger fast hash like SHA-512:
- The point of Argon2 is to make the computation of the password hash require a lot of hardware so that the attacker cannot cost-efficiently crack passwords in massively parallel hardware like GPUs, FPGAs or custom silicon;
- The point of SHA-256 or SHA-512 is to compute hashes quickly for inputs that aren't easy to guess, and to make it hard for attackers to find any collisions.