Describe how hashing and salting protect stored passwords, and identify weaknesses in storing passwords in plain text or with reversible encryption

What this dot point is asking

NESA wants you to explain why secure systems store passwords as hashes (not as encrypted text or plain text), describe what salting adds, and identify the weaknesses in each weaker storage approach.

The answer

Why not plain text

If passwords are stored as plain text, any database breach hands every password to the attacker. Worse, because people reuse passwords across sites, a breach of one site compromises accounts on many other sites.

Why not just encryption

Encryption is reversible. If the password column is encrypted with AES, the encryption key must also be on the server (or accessible to it) to verify logins. If the attacker steals the database, they usually also steal the key. Plain text and encrypted-with-known-key storage are equally bad.

Hashing

A hash function takes any input and produces a fixed-length output. Good cryptographic hash functions are:

• One-way: you cannot recover the input from the hash.
• Deterministic: the same input always produces the same hash.
• Collision-resistant: two different inputs almost never produce the same hash.

When a user signs up, the server hashes the password and stores only the hash. When they log in, the server hashes the submitted password and compares hashes. The password itself is never stored.

Salting

A salt is a random string (typically 16+ bytes) generated uniquely per user and combined with the password before hashing. Salting defeats two precomputed-attack categories:

• Rainbow tables: precomputed hash-to-password lookups for common passwords. With a unique salt per user, every user's effective password is different, and a single rainbow table cannot cover them all.
• Hash sharing: two users with the same password no longer have the same hash, so an attacker cannot see which accounts share a password.

The salt is stored alongside the hash. It does not need to be secret - its job is to be unique.

Slow hash functions

General-purpose hashes like SHA-256 are too fast: a GPU can compute billions per second, so brute-forcing weak passwords is cheap. Password storage uses deliberately slow hash functions:

• bcrypt: a tunable work factor lets you control how slow it is.
• scrypt: also memory-hard, defeating GPU and ASIC attacks.
• Argon2: the modern winner of the Password Hashing Competition.

Each takes hundreds of milliseconds per hash by design - fast enough for login (one hash) but billions of times too slow for brute force attacks.

Worked code

Python with the bcrypt library:

import bcrypt

# At signup:
password = b"correct horse battery staple"
salt = bcrypt.gensalt(rounds=12)
hashed = bcrypt.hashpw(password, salt)
# Store only `hashed` in the database.

# At login:
submitted = b"correct horse battery staple"
if bcrypt.checkpw(submitted, hashed):
    print("Login OK")
else:
    print("Wrong password")

bcrypt produces a hash that contains the algorithm, work factor, and salt all packed together, so no separate salt column is needed.