Password Hashing: What NOT to Do

The Golden Rule

Now let's explore what NOT to do and why these mistakes are dangerous.

Mistake #1: Storing Plaintext Passwords

INSERT INTO users (username, password) VALUES ('alice', 'MyPassword123');

Why it's dangerous:

• -Database breach exposes all passwords immediately
• -Employees with database access can see passwords
• -Users who reuse passwords are compromised on other sites
• -Violates GDPR, CCPA, and most security compliance standards

Mistake #2: Using Fast Hash Functions

password_hash = SHA256(password)  // WRONG!
password_hash = MD5(password)     // EVEN WORSE!

Why it's dangerous:

• -Too fast: Attackers can try billions of passwords per second
• -GPU acceleration: Modern GPUs can compute 100+ billion MD5 hashes per second
• -Rainbow tables: Precomputed tables make cracking instant for common passwords

Mistake #3: Not Using Salt

password_hash = SHA256(password)  // No salt - WRONG!
password_hash = MD5(password)     // No salt - WRONG!

Why it's dangerous:

• -Identical passwords: Users with the same password have the same hash
• -Rainbow tables: Precomputed tables work against all users
• -Pattern detection: Attackers can identify common passwords by hash frequency

alice: password123 → 5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8
bob:   password123 → 5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8
carol: password123 → 5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8

alice: password123 + salt_a → 8f3d9e2a1b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e
bob:   password123 + salt_b → 1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b
carol: password123 + salt_c → 9f8e7d6c5b4a3f2e1d0c9b8a7f6e5d4c3b2a1f0e9d8c7b6a5f4e3d2c1b0a9f8e

Mistake #4: Using a Global Salt

GLOBAL_SALT = "my-app-secret-salt-2024"
password_hash = SHA256(GLOBAL_SALT + password)  // WRONG!

Why it's dangerous:

• -If the salt leaks (source code, config file), all passwords are vulnerable
• -Attackers can build rainbow tables specifically for your salt
• -Same password still produces the same hash across users

Mistake #5: Rolling Your Own Crypto

// "I'll make it more secure by hashing multiple times!"
password_hash = SHA256(SHA256(SHA256(password)))  // WRONG!

// "I'll add my own salt and pepper!"
password_hash = SHA256(salt + password + pepper + timestamp)  // WRONG!

Why it's dangerous:

• -Cryptography is hard. Experts spend years designing secure algorithms
• -Your custom scheme likely has vulnerabilities you don't know about
• -Multiple SHA-256 rounds are still fast-GPUs can do billions per second
• -You're not smarter than the cryptographers who designed bcrypt/Argon2

Mistake #6: Low Work Factor

// bcrypt with cost=4 (way too fast!)
password_hash = bcrypt.hashpw(password, bcrypt.gensalt(rounds=4))

Why it's dangerous:

• -Low cost factors make hashing too fast, enabling brute-force attacks
• -Hardware gets faster every year-what's slow today is fast tomorrow

The Correct Way

import bcrypt

# Hash password
password = b"user_password"
hashed = bcrypt.hashpw(password, bcrypt.gensalt(rounds=12))

# Verify password
if bcrypt.checkpw(password, hashed):
  print("Password correct!")
else:
  print("Password incorrect!")

const bcrypt = require('bcrypt');
const saltRounds = 12;

// Hash password
const hash = await bcrypt.hash('user_password', saltRounds);

// Verify password
const match = await bcrypt.compare('user_password', hash);
if (match) {
  console.log('Password correct!');
}

// Hash password (uses bcrypt by default)
$hash = password_hash('user_password', PASSWORD_DEFAULT);

// Verify password
if (password_verify('user_password', $hash)) {
  echo 'Password correct!';
}

Security Checklist

Try It Yourself

See the difference between fast and slow hashing: