What is hashing in one sentence?

Hashing runs any input through a one-way function to produce a fixed-length string — a fingerprint — that uniquely represents the input, is fast to compute, and cannot be reversed back into the original.

What is the difference between hashing and encryption?

Encryption is reversible: with the key, ciphertext becomes plaintext again. Hashing is one-way by design and has no key to undo it. You encrypt data you need to read later; you hash data you only need to verify.

Why are passwords hashed instead of encrypted?

So that a database breach does not hand over plaintext passwords. The system stores the hash, and at login it hashes the entered password and compares. Because hashing is one-way, an attacker with the database still cannot trivially recover the original passwords.

A salt is a unique random value added to each password before hashing. It ensures two users with the same password get different hashes and defeats precomputed rainbow-table attacks, since the attacker cannot reuse work across accounts.

Why not use SHA-256 for passwords?

SHA-256 is designed to be fast, which helps an attacker guess billions of passwords per second. Password hashing should use a deliberately slow, memory-hard algorithm like bcrypt, scrypt, or Argon2 to make brute-force attacks expensive.

Glossary · Security

What is Hashing?

Hashing runs any input — a password, a file, a whole database — through a one-way function that spits out a fixed-length string called a hash, or digest. The same input always produces the same hash, a tiny change produces a wildly different one, and crucially you cannot run the function backward to recover the input. It is a fingerprint for data: useful for verifying things are identical without ever revealing what they are.

The properties that matter

A cryptographic hash function has a few non-negotiable properties. It is deterministic — the same input always yields the same output. It is one-way, or preimage-resistant — given a hash, you cannot feasibly find an input that produces it. It is collision-resistant — you cannot feasibly find two different inputs with the same hash. And it has the avalanche effect: flipping a single bit of input changes roughly half the output bits. Common functions include the SHA-2 family (SHA-256) and SHA-3; older ones like MD5 and SHA-1 are broken for security use because collisions can now be manufactured.

Hashing is not encryption

This is the confusion worth killing early. Encryption is reversible: it exists precisely so that someone with the right key can get the original data back. Hashing has no key and no way back — that is the entire point. You encrypt data you will need to read again, like a customer's stored document. You hash data you only ever need to verify, like a password or a file's integrity. Reaching for encryption where you should hash, or vice versa, is a classic and dangerous design mistake.

Hashing passwords correctly

Storing passwords is the canonical use case, and it is easy to get dangerously wrong. You never store the password itself; you store its hash, and at login you hash the entered value and compare. But a plain fast hash like SHA-256 is the wrong tool: because it is fast, an attacker who steals the database can guess billions of candidates per second. The right tools are deliberately slow, memory-hard functions — bcrypt, scrypt, or Argon2 — tuned so each guess costs real time and memory. Each password also gets a unique random salt so identical passwords produce different hashes and precomputed rainbow tables are useless.

Beyond passwords

Hashing quietly powers far more than logins. File integrity checks publish a hash so you can confirm a download was not tampered with. Digital signatures hash a document first, then sign the much smaller hash — the foundation of public key infrastructure. Version control systems like Git name every commit by the hash of its contents. Content-addressable storage and deduplication use hashes as keys. Message authentication codes (HMAC) combine a hash with a secret to prove a message was not altered in transit. The same one-way fingerprint serves all of these.

At QUANT LAB

Correct hashing is one of the first things we check and one of the most common things we have to fix. In our web application builds we hash passwords with a vetted, slow algorithm and per-user salts as a baseline, never a hand-rolled scheme. During a penetration test we regularly find passwords stored as fast unsalted hashes — or, alarmingly, in plaintext — which would turn any breach into a catastrophe. Getting the hashing right is cheap up front and ruinously expensive to retrofit after an incident.

Choosing and tuning a hash

The practical guidance is short. For passwords, use Argon2id where you can, or bcrypt as a well-understood fallback, and tune the cost parameters so a single hash takes a noticeable fraction of a second on your hardware — then revisit as hardware gets faster. For integrity and signatures, use SHA-256 or SHA-3 and retire MD5 and SHA-1 entirely. Never invent your own hash function or your own salting scheme. And remember that hashing protects against the wrong things if the rest of the system — rate limiting, breach detection, key storage — is neglected.

Long-form deep-dives that use this term

All posts

Related terms

Storing credentials or sensitive data?

We build and review authentication and data-handling so the hashing is right the first time. Book a 30-minute call.

Penetration testing