What is hashing — why a website doesn't know your password

Forgot your password — you hit "recover," and the site sends a link to reset it, not the old password itself. Not because that's politer. But because the site doesn't know your password — and never did. It stores not the password, but its imprint.

That imprint is what hashing makes. And it has a tricky property: turning a password into an imprint is easy, but the imprint back into a password is practically impossible. In a couple of minutes you'll understand why this protects you even if the site's database gets stolen.

What hashing is, in plain words

A hash function is a "grinder" for data. You feed in anything: a word, a password, a whole file. Out comes a fixed-length string, something like a3f9c2.... That's the hash, the imprint.

It has three properties that explain everything:

• Same input — same output, always. Hash qwerty today and a year from now — you get exactly the same imprint.
• A tiny change changes everything. Swap one letter — and the imprint becomes completely different, not the least bit similar. There's no such thing as partial resemblance.
• No going back. From the imprint you can't recover the original data. You don't run the grinder in reverse.

An analogy: a fingerprint. From a finger it's easy to take a print. But from a print you can't "assemble" the person. And yet comparing two prints to tell whether it's the same finger is easy. That's exactly how a hash works.

Why a website doesn't store your password

Now the main thing. When you register, the site does not write myPassword123 into its database. It runs it through a hash function and stores only the imprint.

At login the same thing happens: you type the password, the site hashes it again and compares the two imprints. They match — you're in. The password itself never appeared on the server in plain form.

Why the trouble? For your sake. Databases sometimes leak. If they held passwords in the open, an attacker would get them all at once. Having only imprints, they hit a wall: you can't turn them back into passwords.

There's a nuance — salt. Before hashing, a random add-on is attached to each password, unique per user. Then even two identical passwords give different imprints, and precomputed tables of imprints don't work. That's why passwords are hashed not with just any function, but with special "slow" ones (bcrypt, argon2) — deliberately made heavy so brute force isn't worth it. If you're writing login yourself — don't hand-roll hashing, use a ready auth service, it does all this correctly.

Hashing ≠ encryption

People constantly mix these up, and the difference is simple — reversibility.

• Encryption is two-way. You encrypt data with a key — and with the same (or a paired) key you can decrypt it back. That's how HTTPS works: data travels protected, but at the other end it's unwrapped back to the original. Encryption's goal is to hide, then read later.
• Hashing is one-way. There's no way back — by design. A hash's goal is to verify without revealing. That's exactly why passwords are hashed, not encrypted: nobody, not even the site itself, should be able to decrypt them.

You meet hashes where passwords aren't in sight either. Every Git commit has a long ID like 8419b4b3 — that's a hash of its contents; change even one byte and the ID changes. Sites give you a file's hash (a checksum) so you can verify you downloaded exactly that file, unmodified. The same trick — a unique imprint — works both for passwords and for integrity checks.

FAQ

Can a hash be decrypted?

No — you can't "decrypt" a hash, because there's nothing to decrypt: the reverse operation doesn't exist. What attackers actually do is brute force: they hash millions of variants and look for a match. Salt and "slow" hash functions guard against exactly this — they make brute force too long and expensive to pay off.

Why can't you return my old password, only reset it?

Because the site physically doesn't store it — only the imprint, and from an imprint the password can't be recovered. The only option is to let you set a new one. By the way, this is a handy tell: if a service emails you the old password in plain text — it stores passwords insecurely, and that's a warning sign.

Can two different passwords give the same hash?

In theory yes — it's called a collision, since the imprint is shorter than the original data. But with good hash functions the chance of hitting a collision is so small it's negligible in practice. That's why matching imprints are treated as solid proof that the inputs matched too.