Password hashing is the practice of never storing a user’s password directly, but instead storing the output of a one-way function applied to it. When the user logs in, the system hashes the supplied password and compares it to the stored value. Because the function is one-way, an attacker who steals the database does not immediately obtain the passwords themselves.
NIST Special Publication 800-63B makes this a requirement: “Memorized secrets SHALL be salted and hashed using a suitable one-way key derivation function.” A salt is a unique random value mixed into each password before hashing, and NIST requires it to be “at least 32 bits in length.” Salting ensures that two users with the same password produce different stored hashes, which defeats precomputed “rainbow table” lookups that would otherwise reverse common passwords instantly.
The other defense is deliberate slowness. A fast hash can be brute-forced billions of times per second on modern hardware, so password storage uses functions tuned to be expensive. The OWASP Password Storage Cheat Sheet recommends Argon2id as the primary choice, with scrypt as a secondary option, bcrypt for legacy systems, and PBKDF2 (NIST gives a baseline of at least 10,000 iterations, with OWASP recommending far higher counts) where FIPS compliance is required. Tuning the work factor as high as the server can tolerate makes each guess costly for an attacker.
A further optional layer is “peppering”: OWASP describes adding a shared secret, stored separately from the database (for example in a hardware security module), so that the hashes alone are insufficient even if the database leaks. Together, salting, a slow key-derivation function, and optional peppering turn a stolen password database from an instant catastrophe into a slow, expensive, and often unprofitable target.