If you only want the answer: MD5 is not safe for any scenario that must resist a malicious attacker, and neither is SHA-1. Both have been shown to be vulnerable to practical collision attacks and should no longer be used for digital signatures, tamper-resistance verification, or password storage. The only scenario where they remain usable is fast verification with no malicious adversary—for example, confirming a file wasn't accidentally corrupted during transfer.
As for why, and what the correct approach is, each point is explained below.
A hash function compresses any input into a fixed-length output. Because inputs are infinite while outputs are finite, in theory there must exist two different inputs that produce the same hash value—this is called a "collision." Collisions can't be avoided entirely, but a secure hash function must make it computationally infeasible to deliberately produce one.
Being "broken" means someone has found a way to produce collisions far faster than brute force:
Why are collisions dangerous? Imagine an attacker prepares two contracts, one harmless and one malicious, both with the same MD5. They get you to sign the harmless version, then later transfer the signature onto the malicious one—because the hash values are identical, the signature still verifies. That is the real-world threat of a collision attack.
Although hashing is irreversible, if a password is too common an attacker can "compute the answer in advance." The approach is to precompute the hashes of a vast number of common passwords, store them in a lookup table, and simply look up the table when cracking. The most famous optimized version is the "rainbow table," which uses a time-memory chaining technique to drastically reduce storage.
The result: if your website stores the MD5 or SHA-256 of passwords directly in the database, then once the database leaks, an attacker can look them up against a ready-made rainbow table and instantly recover large numbers of weak passwords as plaintext. The problem here isn't that the algorithm is broken, but that there is "no salt" and the "algorithm is too fast."
A "salt" is a random string concatenated with the password before the hash is computed. For example, if a user's password is 1234, the system generates a random salt a8Kx9q for them, and what's actually stored is hash("1234" + "a8Kx9q"), with the salt stored alongside.
Salting delivers two key effects:
1234, but with different salts the hashes stored in the database differ, so an attacker can't single out weak passwords by spotting "which accounts have the same hash."The salt doesn't need to be kept secret; what matters is that it's random, long enough, and different for every user.
Even with salting, general-purpose hashes like MD5 and SHA-256 are still unsuitable for storing passwords, because they're "too fast." These algorithms are designed to process large amounts of data at high speed, but fast is a drawback for passwords—once an attacker has the leaked hashes, they can use a GPU to brute-force billions of password guesses per second.
The correct approach is to use "slow" hash functions designed specifically for passwords. They deliberately consume computing resources, with tunable cost parameters that make a single computation take a fraction of a second—imperceptible for normal logins, yet making large-scale brute force extremely expensive:
These functions usually handle salting internally, so you don't need to concatenate it yourself—just use the corresponding library.
| Algorithm | Type | Collision resistance | Suitable for passwords |
|---|---|---|---|
| MD5 | General-purpose hash | Broken | No |
| SHA-1 | General-purpose hash | Broken | No |
| SHA-256 | General-purpose hash | Currently secure | No (too fast) |
| SHA-512 | General-purpose hash | Currently secure | No (too fast) |
| bcrypt | Password hash | Not applicable | Yes |
| Argon2 | Password hash | Not applicable | Yes (top choice) |
Note that "collision resistance" and "suitable for passwords" are two different dimensions. SHA-256's collision resistance is fine—you can safely use it for file verification and digital signatures—but because it computes too fast, it's not suitable for storing passwords directly.
To experience the differences in what MD5 and the SHA family compute, use this site's tool to calculate multiple algorithms at once and compare their output lengths and results directly.
Use the Hash Generator now