How Passwords Work: Hashing, Salting and Secure Storage Explained

Hello friends!

Welcome to this week’s Sloth Bytes.

I hope you had a great week 😊

🦥 No selling out today

I am genuinely considering selling feet pics, so if you work at a company with a marketing budget please forward this to your boss immediately or the feet come out.

Save yourself and learn more about sponsoring

Most of what we think we know about sloths comes from sloths in zoos

Giphy

How Do Passwords Actually Work?

Have you ever wondered what happens to your password when you create an account?

I never thought about it until I started learning authentication.

For some reason I always thought they saved the password just like that and went along with my day (yeah I’m not the brightest… but you already knew that.)

What Happens When You Type a Password?

When you create an account:

You type ILoveSloths123!.
The password should travel to the server over an encrypted connection such as HTTPS/TLS and should never be logged or stored as plaintext.
The server runs it through a password-hashing function such as Argon2id, bcrypt, or PBKDF2 using a unique random salt and an appropriate work factor.
It stores the encoded password-hash record, which usually contains the salt, algorithm/version information, and parameters needed to verify future attempts.

When you log in again, the server receives the candidate password, passes it and the stored hash record to the password-hashing library, and asks the library to verify it. The application should use the plaintext password only transiently for that operation—do not persist it, echo it into logs, or send it to analytics.

What’s Hashing?

A hash function is a one-way mathematical function that:

Maps an input to an output in a deterministic way
Is designed to make recovering the original input from the output impractical
Changes dramatically when the input changes
For passwords specifically, good password-hashing functions are intentionally slow and configurable so password guessing is expensive

Common password-hashing choices include:

Argon2id — a memory-hard password-hashing design and a strong modern choice when your platform supports it
bcrypt — widely deployed and deliberately slow, though older and with input-length limitations developers should understand
PBKDF2 — standardized and still used where ecosystem/compliance requirements call for it

Do not pick a work factor by copying a number from an old blog post—including this one. Benchmark on your actual infrastructure and follow the current guidance for the library/platform you deploy. The goal is to make verification expensive for attackers while still acceptable for legitimate logins.

// Example with bcrypt using asynchronous APIs
const bcrypt = require('bcrypt');

async function demo() {
  const password = 'ILoveSloths123!';

  // Example only: choose/benchmark the work factor using current guidance
  // for the version and infrastructure you actually deploy.
  const workFactor = YOUR_CONFIGURED_COST;

  const hash = await bcrypt.hash(password, workFactor);
  const isMatch = await bcrypt.compare(password, hash);

  console.log(isMatch); // true
}

demo();

Issues with only hashing

Using a hash is not automatically safe. Password storage needs a purpose-built, slow password-hashing scheme plus a unique salt and sensible parameters.

It’s not enough.

For multiple reasons:

Precomputed attacks: Unsalted hashes of common passwords can be matched against precomputed tables. A unique random salt makes that precomputation far less useful.
Fast general-purpose hashes: Functions such as MD5, SHA-1, and even plain SHA-256 are intentionally fast, which is exactly what you don’t want for password storage.
Identical Passwords: Without unique salts, two users with the same password produce the same hash and reveal that relationship.
Hardware Acceleration: GPUs and specialized hardware can test huge numbers of guesses against fast hashes, which is why password hashing should use a deliberately expensive algorithm and sensible work factor.

Salt (yes even your passwords have seasoning)

A salt is random, per-password data incorporated into password hashing. It does not need to be secret:

Makes identical passwords hash differently
Prevents attackers from using pre-computed tables (rainbow tables)
Is stored alongside the hash, not secretly

Password: password123
Salt A: random-user-specific-salt-A
Salt B: random-user-specific-salt-B

password_hash(password123, Salt A) → different output A
password_hash(password123, Salt B) → different output B

Same password. Different salts. Different stored hashes.

Here’s how to salt your passwords in node:

const bcrypt = require('bcrypt');

const password = 'ILoveSloths123!';
const rounds = 10;

// bcrypt generates a random salt and stores the salt + cost in the encoded hash.
const hash1 = bcrypt.hashSync(password, rounds);
const hash2 = bcrypt.hashSync(password, rounds);

console.log(hash1 === hash2); // false — unique salts
console.log(bcrypt.compareSync(password, hash1)); // true
console.log(bcrypt.compareSync(password, hash2)); // true

Salt vs Pepper

A salt and a pepper are not the same thing:

Salt: unique per password/user, random, and normally stored with the password hash.
Pepper: optional extra secret material kept separately from the password database—for example in a secret manager or HSM-backed system.

A pepper can make a database-only breach harder to exploit, but it adds key-management and rotation complexity. It is defense in depth, not a substitute for proper password hashing.

So Companies Don’t Just Have Our Passwords?

Yep… this is what their user database looks like for passwords:

{
  "username": "Sloth",
  "password": "$2b$10$X9uTnSGSO8rK9R2zgUO3UuDjq4/x.1hZ/S8N1EKBnD0yDJjK6Ez4y"
}

Why Good Sites Don’t Retain or Recover Your Password

The server may receive the password during signup/login, but it should not retain the plaintext after hashing or verification.
The database stores a password hash record, not a reversibly encrypted copy of the original password.
The server can verify a future login without recovering the original password from that record.
If the database is stolen, attackers can still perform offline password guesses. Slow password hashing raises the cost; it does not make weak passwords uncrackable.
This is why “forgot password” should trigger a short-lived, single-use reset flow instead of revealing the old password.
Password hashing protects stored credentials. You still need HTTPS, login throttling/rate limits, secure reset flows, session security, and preferably phishing-resistant MFA/passkeys for stronger account protection.

If you want to keep learning

How two-factor codes work — passwords are one factor; TOTP adds another layer using shared secrets and time-based codes.
How environment variables and secrets leak — protecting passwords is pointless if your API keys and application secrets end up in Git or logs.
How random numbers work in programming — salts, tokens, and security-sensitive values depend on randomness you can actually trust.

With Alexa Plus, Amazon finally reinvents its best product (7 minute read)

Alexa has a new brain.

OpenAI announces GPT-4.5, warns it’s not a frontier AI model (4 minute read)

OpenAI is calling the release its “most knowledgeable model yet,” but initially warned that GPT-4.5 is not a frontier model and might not perform as well as o1 or o3-mini.