Nirmal Ravidas

Posted on May 19

Stop Just Hashing Passwords: Why Salting is Non-Negotiable

#node #security #backend #webdev

When building authentication systems, most developers quickly learn that storing plain-text passwords is a cardinal sin. You learn to hash them using algorithms like bcrypt or Argon2.

But there is a critical step in that pipeline that often gets glossed over: Password Salting.

Without a unique salt, even the most robust cryptographic hash functions can leave your user data exposed. Let’s dive deep into what salting is, why your system will fail without it, and how to write a production-ready implementation using TypeScript.

What is Password Salting?

A salt is a unique, randomly generated string of bytes added to a user's plain-text password before it passes through the hashing function.

Instead of a standard hashing pipeline:

$$\text{Password} \longrightarrow \text{Hash Function} \longrightarrow \text{Output Hash}$$

A salted pipeline looks like this:

$$(\text{Password} + \text{Unique Salt}) \longrightarrow \text{Hash Function} \longrightarrow \text{Output Hash}$$

Because the salt is entirely unique to each user, it completely changes the resulting hash output—even if two users happen to choose the exact same password.

The Fatal Flaw of Saltless Hashing

To understand why this matters, imagine you run a platform where both Alice and Bob use the password Password123!.

If you use a basic, saltless hashing function, their database entries will look identical:

User	Plain Text	Hash Result (Deterministic)
Alice	`Password123!`	`ef92b778...`
Bob	`Password123!`	`ef92b778...`

This determinism hands malicious actors three massive advantages on a silver platter if your database is ever leaked:

1. Bulk Identification

If an attacker cracks Alice's password, they instantly know the passwords of Bob, Charlie, and every other user sharing that identical hash value.

2. Rainbow Table Attacks

Attackers don't even need to guess randomly. They use Rainbow Tables—precomputed databases containing millions of common passwords alongside their corresponding hash values. Cracking a saltless database becomes a simple, near-instantaneous lookup game.

3. Accelerated Brute-Force

An attacker can target thousands of identical user accounts simultaneously because a single password guess checks against every identical hash at once.

The Salted Solution

When we introduce a unique salt for every single entry, the scenario completely shifts:

Alice: Password123! + xA91#k_9f $\longrightarrow$ 8fa01b...
Bob: Password123! + pQ82@z_2a $\longrightarrow$ c7b39d...

The database now holds completely different strings. The rainbow tables are rendered utterly useless because the attacker would have to compute a brand-new rainbow table from scratch for every single user account.

Why Algorithms Matter: SHA-256 vs. bcrypt/Argon2

A common beginner mistake is using standard cryptographic modules like Node's crypto.createHash("sha256") for passwords.

Crucial Rule: SHA-256 is a cryptographic hash, not a password hash.

SHA-256 is designed to verify large chunks of data quickly (e.g., file integrity checks). A modern graphics card (GPU) can calculate billions of SHA-256 hashes per second. If an attacker gets a copy of your SHA-256 hashed database, they can brute-force simple passwords in minutes.

Conversely, password-hashing algorithms like bcrypt and Argon2 are designed to be intentionally slow and resource-intensive. They implement an internal "Work Factor" (or cost factor) that forces the CPU/GPU to loop thousands of times before outputting the final hash. This limits an attacker to testing only a small handful of variations per second, turning a 30-minute attack into an impossible multi-year effort.

Production-Ready TypeScript Implementation

Let's look at a complete, production-grade implementation using TypeScript and the bcryptjs library (which is written in pure JavaScript, eliminating native C++ binding compilation errors across different operating systems).

1. Installation

First, install the package and its corresponding TypeScript types:

npm install bcryptjs
npm install --save-dev @types/bcryptjs

2. The Authentication Service Class

The beauty of modern algorithms like bcrypt is that you do not need to manage or store the salt manually. bcrypt automatically generates the salt, mixes it into the password, and embeds the salt parameters directly into the final output string.

Here is how to encapsulate this safely:

import bcrypt from 'bcryptjs';

export class AuthService {
  // A cost factor of 12 represents a solid balance between security and server performance.
  // Each increment doubles the computational time required.
  private static readonly SALT_ROUNDS = 12;

  /**
   * Hashes a plain-text password using a uniquely generated salt.
   * @param password The raw, plain-text password from the registration form.
   */
  public static async hashPassword(password: string): Promise<string> {
    // bcrypt automatically handles generating a strong secure random salt 
    // and combining it seamlessly into the final string format.
    return await bcrypt.hash(password, this.SALT_ROUNDS);
  }

  /**
   * Verifies an incoming password string against a previously saved hash.
   * @param password The raw password input during a login attempt.
   * @param storedHash The comprehensive hash string fetched from your database.
   */
  public static async verifyPassword(password: string, storedHash: string): Promise<boolean> {
    // Internally, bcrypt parses the storedHash string, extracts the embedded salt,
    // hashes the incoming password with that exact salt, and compares the outcomes.
    return await bcrypt.compare(password, storedHash);
  }
}

How the Stored Hash Looks Under the Hood

If you inspect the string returned by AuthService.hashPassword(), it looks something like this:

$2a$12$R9h/cIPby9A06mM/BDu3ceYvO/5VnSjI7E7g4Z2wR88K/6.nct5tW

Let's break down exactly what bcrypt packed into that single database field:

$2a$ : Identifies the specific version of the bcrypt algorithm used.
$12$ : The cost factor (work factor) parameter ($2^{12}$ iterations).
R9h/cIPby9A06mM/BDu3ce: The first 22 characters of the next block are the randomly generated salt decoded from Radix-64.
YvO/5VnSjI7E7g4Z2wR88K/6.nct5tW: The remaining characters are the actual computed password hash.

Defensive Best Practices Summary

Never Roll Your Own Crypto: Always lean on trusted, audited algorithms like bcrypt or Argon2id.
Keep Cost Factors Updated: As hardware evolves, increase your work/cost factor. 10–12 is a great baseline, but verify it matches your API's latency tolerances.
Enforce HTTPS Always: The best hashing and salting in the world won't save your users if their passwords fly across the network in clear plain text before hitting your backend logic.
Implement Rate Limiting: Prevent automated script-kiddies from hitting your /api/auth/login endpoint millions of times by implementing strict IP and account-based rate limiting.

Final Thoughts

Think of it this way: Hashing protects the user's password. Salting protects the integrity of the hash itself.

By ensuring your auth stack leverages a unique, un-guessable salt combined with a structurally slow hashing algorithm, you transform your system's data architecture from a low-hanging fruit into a highly resilient target.

What is your preferred setup for handling user authentication? Let me know in the comments below!

DEV Community