Why Storing Plaintext Passwords Is Dangerous and How Salting & Hashing Protect Users

Why Plaintext Passwords Are Unsafe

Storing user passwords in clear text allows an attacker who obtains the database to reuse the same credentials on other services, because many users reuse passwords across sites.

One‑Way Hash Functions

A cryptographic hash maps arbitrary data to a fixed‑size value that cannot be reversed. When a password is hashed before storage, the original password is never persisted. During login the supplied password is hashed with the same algorithm and the resulting hash is compared to the stored value.

Rainbow Tables

Attackers can pre‑compute hashes of large sets of common passwords and store the mapping in a “rainbow table”. Modern tables reach terabyte scale, enabling rapid lookup of many hashed passwords.

Salting to Defeat Rainbow Tables

For each password a random string (the *salt*) is generated, concatenated with the password, and the combination is hashed. The salt is stored alongside the hash. Because the salt is unique per user, an attacker must build a separate table for each salt, making the attack infeasible when the salt is sufficiently long and random.

Example of the combinatorial explosion: a 9‑character password using digits and letters yields ~1.38 × 10^16 combinations (≈864 GB of data). Adding one more character or another character class multiplies the search space exponentially.

Multiple Hashing Is Ineffective

Applying several hash functions sequentially does not increase security; the overall strength is limited by the weakest function. Moreover, repeated hashing reduces entropy and can create collisions that are easier to exploit.

Attack Vectors Beyond the Database

Even with salted hashes, passwords can be intercepted during transmission if HTTPS is not enforced. A man‑in‑the‑middle can capture the clear‑text password before it reaches the server.

Practical Recommendations

Generate a strong, cryptographically random salt for each user and store it with the hash.

Use a dedicated password‑hashing algorithm such as bcrypt, scrypt, PBKDF2, or Argon2. If a general hash is required, choose a vetted function like SHA‑256/512 or SHA‑3, but apply a key‑stretching layer.

Enforce HTTPS for all client‑server communication to protect credentials in transit.

Avoid client‑side hashing with a fixed salt unless HTTPS is impossible; a fixed salt (e.g., username) does not protect against replay attacks.

Illustrative Formulas

The following images show typical hash‑and‑salt constructions used in practice.