Secure Password Storage: Salting, Hashing, and Key Derivation

Every week, a new headline announces that millions of user accounts have been compromised in a database breach. When the dust settles, the autopsy almost always reveals the same catastrophic engineering failure: the company stored user passwords in plain text, or used outdated, fast hashing algorithms like MD5 or SHA-1.

As a backend engineer, securing user credentials is a foundational responsibility. In this guide, we will trace the evolution of secure password storage and outline the current cryptographic standards.

If you store a user's password exactly as they typed it (e.g., hunter2) directly in your PostgreSQL database, a single SQL injection vulnerability or stolen backup drive immediately compromises every user's account. Even worse, because users notoriously reuse passwords across sites, a breach in your system compromises their bank accounts and email.

The first step in defense is Hashing. A cryptographic hash function takes an input string and converts it into a fixed-length string of characters (the hash). Crucially, hash functions are one-way mathematical operations. You cannot easily reverse a hash back into the original text.

When a user logs in, the backend hashes the password they submitted and compares it against the hash stored in the database. If the hashes match, the password is correct. The database never needs to know the actual password.

However, simple hashes (like SHA-256) are vulnerable to a specific attack: Rainbow Tables.

Because hashes are deterministic (the same input always produces the same output), attackers pre-calculate the hashes for billions of common passwords and store them in massive lookup tables (Rainbow Tables). If they steal your database, they just look up the stolen hashes in their table to instantly find the original passwords.

The solution is Salting. A salt is a long, randomly generated string added to the user's password before hashing (e.g., hash(password + salt)). The salt is stored in plain text alongside the hash in the database.

Because every user gets a unique, random salt, an attacker's pre-computed rainbow table becomes completely useless. They must generate a new rainbow table for every single user in the database, making the attack computationally infeasible.

Salting defeats rainbow tables, but it doesn't stop brute-force attacks. Algorithms like SHA-256 are designed to be extremely fast. A modern cluster of graphics processing units (GPUs) can calculate billions of SHA-256 hashes per second, allowing an attacker to rapidly guess a user's password even if it is salted.

To combat this, we use Key Derivation Functions (KDFs). KDFs are specifically designed to be slow and computationally expensive. They incorporate a "work factor" (or "cost") that dictates how many iterations the algorithm must perform before spitting out the hash.

By artificially slowing down the hashing process (e.g., taking 250 milliseconds to calculate one hash), you make it impossibly expensive for an attacker to brute-force a stolen database, while a 250ms delay is imperceptible to a legitimate user logging into your app.

Today, there are two industry-standard KDFs you should use:

• bcrypt: The battle-tested standard. It automatically handles salting and allows you to configure the cost factor. It is highly resistant to GPU cracking because it requires constant memory access.
• Argon2: The winner of the Password Hashing Competition (PHC). It allows you to configure not just CPU time, but also memory consumption, making it highly resistant to cracking via specialized hardware (ASICs).

Karuvigal provides tools to generate and verify bcrypt hashes directly in your browser, allowing developers to safely test their authentication flows and understand the underlying mechanics of modern cryptography.