In the early days of web development, many applications stored user passwords as plain text in the database. This meant that if the database was breached, hackers could immediately see every user’s password. Even worse, because people reuse passwords, this led to devastating credential stuffing attacks across other sites.
To solve this, developers introduced Hash Algorithms.
The Magic of Hashing: Irreversibility
A hash function is a mathematical algorithm that maps data of arbitrary size to a fixed-size string (the hash value). Its defining characteristic is being one-way (irreversible): it’s trivial to compute the hash of “password123”, but practically impossible to reverse the hash back to “password123”.
The secure login flow:
- On registration: The server hashes the password and stores the hash.
- On login: The server hashes the inputted password and compares it against the stored hash.
The Fall of MD5 and Rainbow Tables
Years ago, MD5 was the go-to algorithm. However, hackers realized they could precompute the MD5 hashes of billions of common passwords, creating massive Rainbow Tables. With a database dump, they could just look up the hashes in their table to crack millions of passwords instantly.
The Savior: “Salting”
To combat rainbow tables, security experts invented “salting”. A salt is a long, randomly generated string. Before hashing, the system appends (or prepends) this salt to the user’s password.
Even if two users have the exact same password (“123456”), because they are assigned different salts, their final database hashes will be completely different. This renders precomputed rainbow tables useless.
Modern Cryptography Best Practices
Today, algorithms like MD5 and SHA-1 are strictly forbidden for password storage because they calculate hashes too quickly, making them vulnerable to brute-force attacks.
The modern developer standard: Use “slow” hash algorithms specifically designed for passwords, like bcrypt, Argon2, or scrypt. These algorithms automatically handle random salting and allow developers to configure a “cost” factor. The higher the cost, the longer it takes to compute a hash (e.g., tens of milliseconds). A normal user won’t notice a 50ms delay during login, but to a hacker trying to guess hundreds of thousands of passwords per second, it is a devastating bottleneck.