Why can't a website tell you your forgotten password?
A well-built site never stored your password in the first place — only a one-way scramble of it, which can be checked against but cannot be turned back.
Simple intuition
The plain reason, in everyday words
When you set a password, a properly built site does not keep it. It runs the password through a one-way process that produces a scrambled result, stores only that, and throws the password away. Next time you log in, it scrambles what you typed the same way and compares the two scrambles. If they match, you knew the password. At no point does the site need the original, and at no point can it work backwards from the scramble to recover it. That is the whole design, and the reason for it is simple: databases get stolen. If the site kept your actual password, a single breach would hand an attacker every password — and since people reuse them, that means their email and bank accounts too. So being unable to tell you your password is not an inconvenience the site has failed to fix. It is the point.
The site has your password but refuses to send it for policy reasons.
A correctly built site genuinely cannot produce it. It holds a one-way transformation that can be checked against but not inverted.
Hashing alone is enough to protect a password database.
Without a unique salt, identical passwords hash identically and precomputed tables crack them en masse. Without deliberate slowness, an attacker can try billions of candidates per second.
Encryption and hashing are the same thing here.
Encryption is reversible with a key, which means a stolen key exposes every password. Hashing has no key and no inverse, which is why it is the correct choice for storage.
Complex character requirements make passwords strong.
Length and unpredictability matter far more. Current guidance favours long passphrases, checking against known-breached lists, and dropping both composition rules and forced periodic changes.
It turns an everyday annoyance into a visible security property, and gives you a one-question test for any service you use: if it can tell you your password, it stored it badly. The underlying idea — verify without retaining, so that a breach reveals less than the thing being protected — recurs throughout security, in signatures, in zero-knowledge proofs, and in the passkey systems now replacing passwords entirely.
Who worked it out
Password hashing dates to the early Unix systems of the 1970s, where Robert Morris and Ken Thompson introduced both hashing and salting, explicitly to make precomputation useless.
What problem forced it
As computers got faster, general-purpose hash functions became far too quick for the job, and by the 2000s a stolen file of unsalted fast hashes could be cracked at enormous rates on commodity graphics hardware.
How it changed since
Purpose-built slow functions followed — bcrypt in 1999, scrypt in 2009 — and the Password Hashing Competition selected Argon2 in 2015. The current trajectory is away from shared secrets entirely, toward public-key credentials such as passkeys.
How passkeys remove the shared secret
The server stores a public key and there is nothing worth stealing, which is where authentication is heading.
Why password reuse is the real danger
Credential stuffing turns one badly protected site into a compromise of the accounts that matter.
Written for Curio rather than collected from a forum — it is part of the curated corpus that ships with the platform. The references it draws on are listed under Sources.