Password Hashing and Salting: Store Credentials Securely

WHY IT EXISTS: The goal is to protect user credentials even if your database is compromised. If you store passwords in plaintext, a single data breach exposes every user's password, which they may have reused on other sites. Hashing and salting makes a stolen database of credentials almost useless to an attacker.

THE MENTAL MODEL: Hashing is a one-way function, like turning a cow into a burger—you can't reverse the process. Salting is like adding a unique spice blend to each cow before grinding. Even if two users have the same password, their unique salts ensure their stored hashes will be completely different, preventing attackers from identifying common passwords or using pre-computed lookup tables (rainbow tables).

HOW IT WORKS: When a user signs up, you generate a unique, random string called a salt. You combine this salt with their password and feed the result into a strong, slow hashing algorithm like Argon2id, scrypt, or bcrypt. You store both the resulting hash and the salt in your database—never the original password. When the user logs in, you retrieve their salt, combine it with the password they just entered, and run it through the same hashing algorithm. If the new hash matches the stored one, access is granted. The slowness is a feature; these algorithms are designed to be computationally expensive to slow down attackers trying to brute-force guesses.

WHEN TO USE IT: Always use this process for storing any secret that a user provides for authentication, primarily passwords. It is a non-negotiable, foundational requirement for any system with user accounts, from web applications to mobile apps.

WHEN NOT TO USE IT: Do not use password hashing for data that needs to be retrieved in its original form. Hashing is a one-way process. If you need to store sensitive information that your application must decrypt and use later, such as an API key, you need two-way encryption, not one-way hashing.

ONE CANONICAL EXAMPLE: The recommended modern standard is Argon2id. A secure configuration might use Argon2id with 19 MiB of memory, an iteration count of 2, and a parallelism of 1. If Argon2id isn't available, scrypt and bcrypt are strong alternatives. A common but critical mistake is using a fast hashing algorithm like SHA-256. While secure for other purposes like file checksums, it is dangerously fast for passwords, allowing an attacker with your stolen hashes to make billions of guesses per second.