Quick questions on Hashing and password storage explained: HSC Software Engineering Module 1

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.

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.

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

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:

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:

Python with the bcrypt library:

The salt does not need to be hidden. It is stored in plain text next to the hash. Its job is to be unique, not secret.

A single global salt defeats only one rainbow table; the attacker can build a new one for your salt. Per-user salts force per-account work.

Encryption is reversible. If the key leaks, every password is exposed. Hashing is one-way and is the only correct approach for password storage.

Even with bcrypt, an attacker who can hit your login endpoint can run online dictionary attacks. Rate limit, lock accounts after failed attempts, and log the failures. :::