Learn & Understand

Hashing Passwords Properly: Salt, Slow Hashes, and Rainbow Tables

The companion calculator generates cryptographic hashes with algorithms like SHA-256, and rightly notes their one-way, fingerprinting nature. Those general-purpose hashes are excellent for file integrity, but using them directly to store passwords, a common instinct, is a serious mistake. Password storage has its own requirements that fast, general hashes fail to meet, and getting it wrong is behind many of the credential leaks that lead to account takeovers. Understanding salts, slow hashing, and the rainbow-table attacks they defend against is essential defensive knowledge.

Never Store Passwords in Plaintext

The first principle is that a system should never store the actual passwords its users choose. If the database is stolen, and databases are stolen constantly, plaintext passwords hand the attacker every account instantly, and, because people reuse passwords, accounts on other sites too. The standard defense is to store a hash of the password instead: when a user logs in, the system hashes what they typed and compares it to the stored hash, so the real password is never kept. But hashing alone, with a general-purpose fast hash, is not enough, and understanding why is the heart of proper password storage.

The Rainbow-Table Problem

A fast hash has a weakness for passwords: the same password always produces the same hash, so an attacker can precompute the hashes of millions of common passwords once and simply look up stolen hashes against that table, a rainbow table. This turns cracking into instant lookups.

The speed that makes SHA hashes great for checksums is exactly what makes them dangerous for passwords: an attacker can try guesses at enormous rates.

Salt: Making Every Hash Unique

The first fix is a salt, a unique random value added to each password before hashing and stored alongside the hash. Because every user's salt is different, the same password produces different hashes for different users, which defeats precomputed rainbow tables entirely, an attacker would need a separate table per salt, which is infeasible. Salting also hides the fact that two users chose the same password. Salting is non-negotiable in proper password storage, and it costs almost nothing to implement. It ensures that cracking must be done per-password rather than once for everyone.

Slow Hashes: Deliberately Expensive

Salting stops precomputation, but a determined attacker can still guess passwords one at a time against a stolen hash. The second fix addresses this by making each guess expensive. Purpose-built password-hashing functions, such as bcrypt, scrypt, and the modern Argon2, are deliberately slow and tunable, taking a meaningful fraction of a second and, in some cases, a large amount of memory per hash. For a legitimate login, one slow hash is imperceptible. For an attacker trying to test billions of guesses, that same slowness is devastating, reducing their guess rate from billions per second to a trickle. This is why password storage uses these slow, adaptive functions rather than the fast general-purpose hashes the calculator generates. As hardware improves, their cost factor can be increased to stay ahead.

Understanding Proper Password Storage

Use the calculator's hashes for what they are good at, verifying integrity and fingerprinting data, and understand that storing passwords is a different problem with different tools. Never keep plaintext; hash with a unique salt per password to defeat rainbow tables and hide reuse; and use a deliberately slow, purpose-built function like bcrypt or Argon2 so each guess is expensive. The fast hash proves a file is intact; salted slow hashing is what actually protects the passwords behind a login.