Why are passwords stored using hashes?
Short answer
A service normally stores a hash for checking a password, rather than the password itself. This helps reduce harm if its database is exposed, but hashing is not automatically safe regardless of how it is done.
Checking a password at sign-up and sign-in
When a password is created, the system combines it with a random salt made for that password and runs a password-storage scheme. It stores the salt, information identifying the scheme and its cost settings, and the result. At sign-in, it uses the saved salt and settings to run the submitted password through the same scheme and compares the result with the stored one.
A salt is not a secret key. Different salts produce different hashes even for the same password, so the stored values do not readily reveal whether two people use the same password. Salts also make precomputed hash tables less useful.
Why use a dedicated scheme?
An attacker who obtains a password database can try guesses on their own computer and compare each result with the stored value. A password-storage scheme is designed to use time or memory to slow this kind of offline attack. A fast general-purpose hash such as SHA-256, used on its own, is unsuitable because guesses can be tested quickly.
These schemes have settings that control the effort each calculation takes. Argon2id is one example. Increasing its time or memory cost also makes legitimate sign-ins take more time and computing resources, so a service must choose settings it can handle.
Rate limits address a different risk
Limits on failed sign-in attempts help defend against online attacks that send many guesses to a service. They do not slow guesses against a stolen database. Services need both a suitable password-storage scheme and protections for sign-in attempts. Hashing also cannot make a short, easy-to-guess password safe.