How a site should store your password, and the red flag that says it doesn’t

You can’t control how a website stores your password on its servers. But you can tell, from the outside, when a site is doing it dangerously, and you can limit how much that costs you. It comes down to one question: if the site got breached tomorrow, would your password come out readable?

Plaintext is the cardinal sin

The worst option is storing your literal password as typed. The tell is simple: if a site can email you your current password, or a support agent can read it back to you, they’re keeping it in plain view. That means a single breach spills every user’s real password at once. You can’t fix their choice, but you can shrink the blast radius by making sure that password isn’t used anywhere else. Treat any ‘here is your password’ email as a warning label.

What good storage looks like

A responsible site never stores the password itself. It stores a hash: the output of a one-way function that’s easy to run forward and effectively impossible to reverse. It also adds a unique random salt to each account before hashing, so two people with the same password get different stored values and precomputed attack tables stop working. Modern systems use slow, purpose-built hashes like bcrypt, scrypt, or argon2, which are deliberately expensive to run so that mass cracking crawls. You don’t need the math. You need to know that when this is done right, a stolen file is a pile of useless scrambled values, not a password list.

What you can actually do about it

Since you can’t audit anyone’s backend, assume any site might leak someday and plan for it. Three habits cover you: a unique password for every site, a password manager so that’s painless, and two-factor on anything that matters. Then a breach at one careless company stays contained to that one account. And the sites that email your password back? Never trust them with anything you reuse, and turn on 2FA there first.