A hash function maps input of any size to a fixed-length output, one way, and the same input always gives the same result. Fast hash functions like SHA-256 verify data. Deliberately slow ones like Argon2 and bcrypt store passwords. Using the fast one for passwords is the mistake.
- One way by design, which is what makes it not encryption
- The avalanche effect: one bit in changes half the bits out
- MD5 and SHA-1 are broken for anything an attacker can influence
- A salt is not a secret. It defeats precomputed tables
- HMAC adds a key, and that is what proves who sent a message
On this page
The three propertiesThe three properties that make a hash function cryptographic
Any function that maps input of any size to a fixed-length output is a hash function. The ones used in security have to survive attacks from somebody who knows the algorithm, and that requires three specific properties.
Preimage resistance. Given an output, finding any input that produces it must be infeasible. This is the one-way property, and it is why a stolen table of hashes is not a stolen table of passwords. Attacks against it are guessing attacks rather than reversal.
Second preimage resistance. Given one input, finding a different input with the same output must be infeasible. This is what stops an attacker from substituting a modified file for the original while keeping the published checksum valid.
Collision resistance. Finding any two inputs that produce the same output must be infeasible, even when the attacker chooses both. This is the strongest requirement and the first to fall to new attacks, which is exactly what happened to MD5 and SHA-1.
Two more properties are always present and rarely stated. Cryptographic hash functions are deterministic, so the same input data gives the same digest on any machine forever, and they exhibit the avalanche effect, so changing one bit of the input changes roughly half the bits of the output.
The avalanche effect is why a hash is useful for detecting change: there is no such thing as a small difference in the result.
Where you meet themWhere hash functions actually appear in IT work
Five uses cover almost everything an administrator meets, and their requirements differ.
Password storage. The system stores a hash of the password rather than the password. At login it hashes what was typed and compares. Nobody, including the operator of the system, can read the stored passwords back out. This is the use case with the special algorithm requirement, described below.
File and download integrity. A vendor publishes the SHA-256 digest of an installer, you compute it locally, and matching values mean the bytes are identical. This catches a corrupted download reliably and a tampered one only if the published digest came over a channel the attacker could not also control.
Digital signatures and certificates. Signing hashes the document and encrypts the digest with a private key, because signing a short fixed-length digest is fast and signing a large document directly is not. Every TLS certificate on your network was signed this way, and the collapse of SHA-1 is why certificates moved to SHA-256.
Message authentication with HMAC. An HMAC combines a hash function with a secret key, so the receiver can confirm both that the message data is unchanged and that it came from somebody holding the key.
A plain hash proves neither of those things on its own, because anyone who alters a message can recompute its digest. HMAC is what secures API request signing, webhook verification, session cookies and the integrity of every TLS record, and it is the reason a hash function on its own is rarely the finished control.
Deduplication and change detection. Backup systems, version control and configuration management all identify content by its hash. Git names every object by its digest, and a backup product stores one copy of any block whose hash it has already seen.
Fast and slowFast hashes and slow hashes, which is the distinction that matters
This is the part that gets built wrong, and the error looks reasonable while you are making it.
SHA-256 is designed to be fast. That is correct for a file check, where hashing four gigabytes of data should not take a minute. It is a serious problem for passwords, because an attacker who steals your hash table can compute billions of guesses per second on commodity graphics hardware, and human-chosen passwords do not survive attacks at that speed.
Password hashing algorithms are deliberately slow and deliberately expensive in memory. Argon2, the current recommendation, lets you tune time, memory and parallelism separately. bcrypt has a cost factor that you raise as hardware gets faster, and it has been in production for decades. scrypt is memory-hard, which specifically frustrates the custom hardware that makes brute forcing cheap.
The rule is short. Use fast hash functions such as SHA-256 or SHA-3 for integrity, and Argon2, bcrypt or scrypt for passwords. Using a fast hash for passwords is the single most common cryptographic mistake in application code, and using a slow one for file verification is merely annoying.
Password hashing is also the control that makes a breach survivable, which is why it belongs alongside multi-factor authentication rather than instead of it.
SaltingSalting, and why two identical passwords should not match
A salt is a random value generated per password, stored alongside the hash, and mixed into the input before hashing. It is not a secret and it does not need to be.
Salting defeats precomputation. Without it, an attacker computes the hashes of common passwords once and looks up the stolen table instantly, which is what a rainbow table is and why rainbow table attacks were once so effective. With a unique salt per user, that precomputed data is worthless, because every user password has to be attacked separately.
It also fixes a subtler leak. Two users with the same password produce the same unsalted hash, so a stolen table reveals which accounts share a password without any cracking at all. With salts, identical passwords produce completely different digests.
A pepper is a related idea: a secret value, the same for every user, stored somewhere other than the database, such as in the application configuration or a hardware security module. If the database alone leaks, the hashes cannot be attacked without it.
Modern password hashing libraries handle the salt for you and embed it in the stored string, so the practical advice is to use the library rather than to build this by hand.
What to useWhich algorithms are still safe
Use these. SHA-256 and SHA-512 for integrity, signatures and HMAC, SHA-3 where a different design is wanted, and BLAKE2 or BLAKE3 where speed matters and the ecosystem allows it. For passwords, Argon2id first, then bcrypt or scrypt where Argon2 is not available.
Do not use these for security. MD5 has been fully broken since 2004 and producing colliding files is a laptop-scale exercise. SHA-1 fell to a practical collision attack in 2017 and has been removed from certificates and signatures everywhere. Neither is a secure choice for anything an attacker can influence.
The nuance about MD5. It remains perfectly good as a fast non-cryptographic checksum against accidental corruption, and vendors still publish MD5 sums for that reason. It is worthless against an attacker who is deliberately crafting a file, and it should never be used where the difference matters.
PitfallsWhere people go wrong
Calling hashing encryption. Encryption is reversible with a key and hashing is not reversible at all. Neither is key exchange, which is a third thing again. A system that can email you your existing password is not hashing anything.
Using SHA-256 for passwords. It is fast, and fast is the vulnerability. Use a password hashing algorithm with a cost factor.
Rolling your own scheme. Hashing twice, mixing algorithms, or adding a homemade transformation makes analysis harder and security worse. Use the library that ships with the platform.
Trusting a checksum from the same place as the file. If an attacker replaced the download, they replaced the digest on that page too. The check is a secure one only when the digest travels separately or is signed.
Storing the salt somewhere clever. The salt is not a secret. Store it with the hash, which is what every password library already does, and put the effort into the cost factor instead.
Assuming a hash proves who sent the data. It proves the message is unchanged and says nothing about the sender, because anyone can recompute a digest. Proving origin takes an HMAC with a shared key, or a signature with a private one.
Never raising the cost factor. A bcrypt cost chosen in 2015 is far too cheap on 2026 hardware. Raise it on password change, and revisit it on a schedule.
ComparisonFour things that get confused, and the column that is not security at all
| Criterion | Hashing | Encryption | Encoding | Salting |
|---|---|---|---|---|
| Reversible | No, ever | Yes, with the key | Yes, by anyone | Not applicable |
| Needs a key | No | Yes | No | No, a random value |
| Output length | Fixed | Varies with input | Varies with input | Adds a stored value |
| What it is for | Integrity and passwords | Confidentiality | Transport and display | Defeating precomputation |
| Security value | High, if the algorithm holds | High | None at all | Only alongside hashing |
| Typical example | SHA-256, Argon2, HMAC | AES, RSA | Base64, URL encoding | A random 16-byte value |
The row that catches people is the encoding column. Base64 looks like a hash to the untrained eye and provides no security whatsoever, which is why finding Base64 in a password field is always a finding rather than a false alarm.
FAQFrequently asked questions
What are hash functions?
Functions that turn input data of any size into a fixed-length output, deterministically, so the same input always produces the same digest.
What makes hash functions cryptographic?
Three properties: you cannot find an input for a given output, you cannot find a second input matching a given one, and you cannot find any two inputs that collide. Without all three, the function is a checksum rather than a secure primitive.
What is HMAC?
A construction that combines a hash function with a secret key so the receiver can verify both that the message data is unchanged and that it came from somebody holding the key. It is what signs API requests and webhooks.
Is hashing the same as encryption?
No. Encryption is reversible with a key and exists to keep data confidential. Hashing is one way and exists to verify data or to store passwords in a form nobody can read back.
Can a hash be reversed?
Not by computation. An attacker can guess inputs and compare digests, which is what password cracking is, and that is why the choice of algorithm matters so much for passwords.
What is a collision?
Two different inputs producing the same output. Collisions exist mathematically for every hash function, and a good one makes finding them infeasible in practice.
Is MD5 still safe?
Not for anything security related. Practical collision attacks have been available for two decades. It remains fine as a fast checksum against accidental corruption of data.
Is SHA-1 safe?
No. A practical collision was demonstrated in 2017 and it has been removed from certificates and signature use. Treat it as broken.
Which hash should I use for passwords?
Argon2id first, or bcrypt or scrypt where it is not available. Never a general purpose hash like SHA-256, because its speed is the attacker's advantage.
Why is SHA-256 wrong for passwords when it is not broken?
Because it is fast by design. An attacker with a stolen hash table can compute billions of guesses per second, and only a deliberately slow algorithm makes that expensive.
What is a salt?
A random value per password, mixed in before hashing and stored with the result. It defeats precomputed tables and stops identical passwords from producing identical hashes.
Does the salt need to be secret?
No. It works by being unique, not by being hidden. A secret value shared across all users is a pepper, and it is a separate control stored outside the database.
What is the avalanche effect?
Changing one bit of input data changes about half the bits of the output. It is why hash functions detect any change at all, however small the change was.
How do I verify a downloaded file?
Compute the SHA-256 digest locally and compare it to the published one. The check only proves something if the published digest came from a channel an attacker could not also alter.
Why do digital signatures hash the document first?
Because signing a short fixed-length digest is fast and signing a whole document with a private key is not. The signature covers the digest, and the digest covers the document.
Keep readingRelated concepts
Read next · Identity and access What Is MFA? Password hashing decides how bad a stolen database is, and this decides whether the password alone was ever enough. Open this next16 min- Identity and access · 13 min Zero Trust Explained What replaces trusting a credential once, which is the assumption every password store inherits.
- Cryptography · 12 min Diffie-Hellman Key Exchange The other piece of cryptography that gets called encryption and is not, which makes the pair worth reading together.
- Firmware and boot · 10 min Checksum Errors, and Why the Battery Is Usually the Answer Where checksums become cryptography.
- Cryptography · 11 min Encryption Algorithms, and the Two Families They Fall Into What is not encryption, and why the confusion matters.
- Operations · 14 min What a Webhook Is, and the Four Things That Break One How the signature check actually works.
- Ports · 10 min TACACS+ vs RADIUS, Port by Port and Claim by Claim A working example of MD5 collisions breaking a protocol in production.