Hashing
A one-way fingerprint of data: easy to compute, not meant to be reversed.
A hash function takes any input (a word, a file, a whole disk) and produces a short, fixed-size string called a hash: SHA-256 always gives 64 hexadecimal characters. The same input always gives the same hash. Change one letter and the hash is completely different. And there is no way to run it backwards: from the hash you cannot rebuild the input, and finding two inputs with the same hash is, for a good function, impractical.
That makes hashes useful as fingerprints. A download page shows the file's hash so you can check your copy is intact. Git names every commit by a hash of its content. Blockchains chain blocks by hashing the previous one. And websites store a hash of your password instead of the password: when you log in, they hash what you typed and compare. If the database leaks, the attacker gets fingerprints, not passwords.
The catch with passwords is that attackers can hash billions of guesses per second and compare. So passwords are hashed with slow, purpose-built functions (bcrypt, scrypt, Argon2) and a random salt per user, so that the same password gives different hashes for different people and precomputed tables are useless. A fast hash like MD5 for passwords is a classic mistake that keeps appearing in breach reports.
Hashing is not encryption. Encryption is reversible with the key; a hash has no key and no way back. If a site can email you your old password, it was not hashing it.
Keep in mind
- Same input, same hash; a tiny change gives a completely different hash.
- It is one way: the hash does not reveal the input.
- Passwords should be stored as slow, salted hashes (Argon2, bcrypt), never as plain text.
- Hashing verifies and identifies; encryption hides. They are different tools.