MD5 vs SHA-256: which is safer?

Why MD5 is no longer enough

MD5 can still catch accidental file changes in low-risk scripts, but it is broken for collision resistance. Different inputs can be crafted with the same MD5 hash, so MD5 is not suitable for signatures, certificates, tamper-resistant integrity checks, or password handling.

Example

Need a file checksum for accidental corruption
Need a security-sensitive integrity check

Low risk: SHA-256 is still a good default
Security-sensitive: use SHA-256 or a purpose-built modern construction

How to choose a hash

1. Choose SHA-256 for file integrity checks and public checksums when you control the algorithm.
2. Keep MD5 out of signatures, certificate checks, security tokens, and tamper-resistant workflows.
3. For passwords, use a password hashing algorithm such as bcrypt, scrypt, or Argon2 instead of a fast hash.
4. When a vendor publishes a checksum, match their algorithm, but prefer vendors that publish SHA-256 or stronger hashes.

Checksums and trust

A checksum tells you whether two copies match. It does not prove the original source was trustworthy unless the checksum came from a trusted channel.

For downloads, compare SHA-256 values from the official site or release notes. For packages, lean on the package manager's signature and lockfile checks instead of hand-rolled hash checks.

Passwords are different

Password storage needs slow, salted password hashing. Fast hashes such as MD5 and SHA-256 are built for speed, which helps attackers test guesses quickly.

For authentication, use a maintained password hashing library and follow its defaults. The hash you use for a file checksum is not the hash you want for passwords.

Common mistakes

• Using MD5 because it is shorter and easier to paste
• Treating a hash as encryption
• Hashing passwords with a fast general-purpose hash
• Assuming SHA-256 alone proves a file is trustworthy without a trusted source

Related problems