Why should we protect the access to the password hashes? And under what conditions can this precaution be omitted?
Safe password storage algorithms have two main features: they're one-way, and they're slow.
- Being one-way means that given the output, you cannot efficiently compute the input. Efficient means: anything faster than trying all inputs until you get a matching output.
- Being slow means that computing an output (the stored value) from the input, takes a while. Because they're one-way, you need to try inputs, and if trying an input takes ten billion calculations on your CPU, then it's going to take a while before you checked all possible passwords.
But what if your password is in the top 10 of worst passwords, like "admin" or "123456"? Then an attacker is going to guess that within a few attempts, no matter how strong your hashing algorithm is.
Therefore, people with weak passwords will always be at risk if their hash is known to an attacker. That's why we keep them secret.
When we log in to a system, we don't want to wait 5 minutes for the server to complete the password algorithm, so those algorithms are still quite fast (something like 0.1 seconds). Because computers get faster over time, we also need to increase the number of computations done, so that it still takes an attacker (with modern hardware) a long time. Or maybe we want to upgrade to a different algorithm that protects against a certain kind of ASIC or GPU cracking program. In those cases, if the old hash is known to an attacker, they can crack the user's password more easily. So additionally, keeping the hashes secret as long as possible, we also have the most up-to-date protection at the moment the hashes get hacked.
Some people include pepper in their password hashes (see this question or Wikipedia), in which case it would be perfectly safe to publish the password hashes so long as the pepper value remains a secret. But then the question is: why would you? There is usually no advantage to publishing the hashes. When the pepper value leaks, attackers can start cracking the oldest hashes you ever published. If you protect the hashes instead of posting them publicly, attackers first have to obtain both the pepper and the user database before they can start cracking anything.
Omitting this precaution (of protecting password hashes) should never be done without the user being warned of the risk. One example of this is a tripcode, where the hash gets published as proof of identity without needing a database. This is the only case that I can think of where publishing hashes of memorized secrets is a good idea. Other hashes, such as signatures of software, are of course a different topic because those do not function as passwords.
I agree all the answers written before me, but would like to answer this question briefly:
We have to protect the hashes because that's what all hackers or pentesters want to get as to crack the hashes and find the passwords through brute-forcing, dictionary attacks, and rainbow tables. If you make easy to access them to your password hashes, you will make them very happy, for sure.
If you protect the hashes you protect your weak passwords.
Over the years the recommended password hashing algorithms have changed several time as vulnerabilities, and unexpected technological advances have occurred. There's no 100% guarantee that a hash which is safe today will still be safe in 10 year.
By protecting the hashes from being accessed by an attacker you mitigate your risk of compromise in the case where a hash is captured, and it is cracked in the future.
This is also a reason why multiple organizations require passwords to be changed on a regular basis.
There's been many large attacks where password databases get dumped, and eventually cracked. Rockyou is one of the most notable ones, it's wordlist is included in all Kali instances now. Hashes simply slow down an attacker. While some people will look at the math and say "oh, it's totally safe, it would take X million years to crack this", that's not always realistic when we see new vulnerabilities and shifts in computing paradigms all the time.