How Your Passwords Are Actually Stored (And Why Plaintext Is a Disaster)

Every time a major breach makes headlines, the follow-up question is always the same: were the passwords stored properly? The gap between "properly" and "not properly" is the difference between a breach that inconveniences a security team and one that hands attackers millions of working logins on other sites too.

Why plaintext storage is an unrecoverable mistake

If a site stores your password as literally the characters you typed, then the moment that database is breached, every account is instantly and completely compromised — no cracking required. Worse, because most people reuse passwords across services, a plaintext breach on one unimportant site can cascade into compromised email, banking, and work accounts elsewhere. This is precisely why "never store plaintext passwords" is treated as an absolute rule in security engineering, not a best-practice suggestion.

Hashing is not encryption

These two get confused constantly, but they solve different problems. Encryption is reversible — encrypt with a key, decrypt with a key, get the original data back. Hashing is deliberately one-way: a hash function takes an input of any size and produces a fixed-length output, and there's no key or process that turns that output back into the original input.

Passwords should be hashed, not encrypted, because the server never actually needs to know your password — it only needs to verify you know it. At login, the server hashes whatever you typed and compares that new hash against the stored one. If they match, you typed the right password; the server never had to store or even reconstruct the original.

Why "just hash it" still isn't enough

Early systems hashed passwords with general-purpose algorithms like MD5 or SHA-1. The problem: those algorithms were designed to be fast, because they're also used for things like verifying file integrity, where speed is a feature. Fast is exactly what you don't want for password hashing, for two reasons:

• Rainbow tables — precomputed lookup tables mapping common passwords to their hashes. If your hash matches an entry, the attacker instantly knows your password without any real cracking effort.
• Brute-force speed — a fast hash function lets an attacker with modern GPU hardware attempt billions of guesses per second against a stolen hash database.

Salting fixes the rainbow table problem: a unique random value is generated per user and mixed into the hash input, so two users with the identical password end up with completely different stored hashes, and precomputed tables become useless — an attacker would need a separate table per salt, which defeats the entire point of precomputing.

Salting alone doesn't fix the brute-force speed problem though — that requires the hash function itself to be slow on purpose.

Purpose-built password hashing algorithms

Modern systems use algorithms specifically engineered to be computationally expensive — bcrypt, scrypt, and Argon2 (the current recommended standard, winner of the 2015 Password Hashing Competition). They build in:

• Adjustable work factor — a deliberate "cost" parameter that makes each hash take a set amount of time (milliseconds for a legitimate login, but that same cost multiplied across billions of attempts becomes prohibitively slow for an attacker).
• Memory hardness (scrypt, Argon2) — the algorithm also requires a significant amount of memory per hash attempt, specifically to blunt the advantage of GPUs and custom cracking hardware, which are extremely fast at parallel computation but comparatively memory-constrained.
• Built-in salting — salt generation and storage is handled automatically as part of the algorithm's output format, removing a common source of implementation mistakes.

This is why security audits treat "are you using bcrypt/Argon2" as close to a pass/fail checkbox, and treat "we use plain SHA-256 for passwords" as a serious finding — SHA-256 is a fine, secure algorithm for what it was designed for, which is not this.

What this means for you as a user

• Password length matters more than cleverness. Against a properly slow hash, a long random passphrase is dramatically harder to brute-force than a short "clever" substitution password (P@ssw0rd! is still weak; length is what actually scales the difficulty).
• Reuse is the real danger. Even a well-hashed database can eventually be cracked for weak passwords given enough time. A unique password per site means a breach on one service can't be used to log into your others.
• A password manager solves both problems at once — long, unique, random passwords for every site, without you needing to remember any of them.
• Enable two-factor authentication where it's offered. It means a leaked or cracked password alone isn't enough to get in.

Frequently Asked Questions

If hashing is one-way, how does "forgot password" work? It doesn't recover your old password — the server can't. It sends a time-limited reset link or code to a separately verified channel (your email or phone) and lets you set a brand new password, which gets hashed fresh.

Can a hashed password ever be "decrypted"? Not through the hash function itself. Attackers instead guess candidate passwords, hash each guess with the same algorithm and salt, and check for a match — which is exactly why slow, memory-hard algorithms make this approach impractical at scale.

Is a longer hash output automatically more secure? Output length matters far less than which algorithm produced it and how much computational cost it imposes per guess — a long output from a fast, unsalted algorithm is still weak.