Why Plaintext Passwords Are Dangerous and How to Secure Them Properly

Is storing passwords in plaintext acceptable?

No. Data stored in a database faces many threats at the application, database, operating system, data‑center, and employee levels, making it virtually impossible to guarantee 100% protection against theft.

If passwords are encrypted before storage, even if the database is leaked, attackers cannot easily obtain the clear‑text passwords. Encryption acts like a safety net for user accounts.

Can we simply encrypt passwords with AES and decrypt when needed?

No. This raises the problem of securely storing the encryption key. Even with separate key storage, achieving zero‑leakage is unrealistic. If the key is compromised, the clear‑text passwords are exposed, making this approach unsuitable.

Instead of storing clear passwords, provide a password‑reset mechanism rather than a retrieval feature.

Would storing only the MD5 hash of passwords be sufficient?

Not all hash algorithms are appropriate; only cryptographic hash functions should be used. Cryptographic hashes have four key properties:

Fast computation for inputs of any size.

Infeasibility of deriving the original input from the hash.

Small changes to the input produce drastically different hashes.

Extremely low probability of two different inputs producing the same hash.

These properties make cryptographic hashes suitable for password protection, though MD5 and SHA‑1 are now considered broken and should no longer be used.

What about storing the SHA‑256 hash of passwords?

No. Attackers can use lookup tables or rainbow tables to reverse‑engineer passwords, especially when passwords are short or have limited character sets.

Simple passwords can be cracked with pre‑computed lookup tables.

For example, an 8‑digit numeric password has only 10⁸ possibilities; a pre‑computed table of all SHA‑256 values can be used to recover the password instantly.

Complex, longer passwords may require rainbow tables, which trade time for space.

Rainbow tables store only the start and end of hash chains, allowing attackers to reconstruct intermediate hashes during cracking.

How can we prevent rainbow‑table attacks?

By adding a unique salt to each password before hashing: store HASH(password + salt) instead of just HASH(password). This renders pre‑computed tables ineffective.

How should salts be generated?

Use a Cryptographically Secure Pseudo‑Random Number Generator (CSPRNG) rather than a simple RNG. Salts must be sufficiently long, never reused, and regenerated each time a password is changed.

Can I design my own proprietary hash algorithm?

No. Designing a secure hash requires deep cryptographic expertise. Without meeting all cryptographic properties, a custom algorithm is likely weaker and gives attackers more avenues for attack.

Is using a unique, high‑quality salt with a standard hash enough?

Modern hardware can compute SHA‑256 billions of times per second, making brute‑force attacks feasible even with salts. Password‑hash algorithms deliberately slow down computation to increase attack cost.

Which password‑hash algorithm should be used?

PBKDF2, Bcrypt, and Scrypt have been popular, each with trade‑offs. In 2015, Argon2 won the Password Hashing Competition and is now recommended, though adoption is still emerging.

Real‑world example: How does a large company store passwords?

Dropbox (2016) hashes passwords with SHA‑512, then applies Bcrypt (unique salt, cost factor 10), and finally encrypts the Bcrypt output with AES using a global key stored in dedicated hardware. This three‑layer approach mitigates risks from each individual step.

Dropbox uses SHA‑512 to normalize password length before Bcrypt, because Bcrypt is input‑size sensitive and truncates long inputs. AES encryption adds an extra protection layer and allows key rotation.