Why a website cannot tell you your own password

This works through password storage in the order the parts actually depend on each other.

One-way by construction

A hash function turns input of any length into a fixed-length value that cannot practically be reversed. A service stores the hash, and when you log in it hashes what you typed and compares the results.

It therefore never needs to hold your actual password, which means a stolen database does not directly hand over credentials. This is why a legitimate service can only reset a password, never retrieve it.

Salt defeats precomputation

Without a salt, identical passwords produce identical hashes, so an attacker can precompute a table of hashes for common passwords once and use it against every stolen database. A unique random salt stored alongside each hash means the same password produces different hashes for different users. That forces an attacker to attack each account separately rather than all of them at once.

A pepper, a secret value stored outside the database, adds a further layer that a database-only breach does not reveal.

Slowness is the point

General-purpose hash functions are designed to be fast, which is exactly wrong for passwords because it lets an attacker try billions of guesses. Purpose-built password hashing functions are deliberately slow and are tuned to consume significant memory as well as time. Memory cost matters because it removes the advantage of specialised parallel hardware, which is otherwise enormous.

The work factor is adjustable so that it can be raised as hardware improves, which is a design that ages well.

What a breach actually exposes

With modern hashing and a strong unique password, a stolen database yields very little even to a determined attacker. With outdated fast hashing and no salt, common passwords fall in seconds and the database is effectively plaintext. Breach notifications rarely state which was used, so the safe assumption after any breach is that the password is compromised.

Email addresses, security questions and personal details in the same breach are frequently more damaging than the password itself.

Reuse is the real vulnerability

Attackers take credentials from one breach and try them automatically against many other services, which is credential stuffing. It succeeds because password reuse is extremely common, and it needs no cleverness at all.

Mechanically, a unique password per service confines any breach to that one account, which is the entire argument for a password manager. Length matters more than complexity rules, and a long passphrase beats a short string of substituted symbols.

Implementations differ, and vendors are not obliged to document the differences.

What good practice looks like from outside

A service that emails your existing password, limits password length or forbids pasting is signalling poor internal practice. Offering multi-factor authentication, notifying on new logins and supporting long passwords are positive signals.

In the datasheet, forced periodic rotation without cause has fallen out of favour in major guidance because it pushes users towards predictable variations. The strongest single improvement most people can make is a manager plus a second factor on email, since email resets everything else.

The takeaway

A service that can show you your password never protected it. Unique passwords are what limit the damage.

The constraint is almost always physical, and marketing rarely mentions which one.