Why MD5 Is Unsafe for Passwords and How to Choose Secure Hashing Algorithms

Hash Algorithm Types

Cryptographic hash algorithms : Provide higher security and data integrity protection, suitable for security‑critical scenarios (e.g., SHA2, SHA3, SM3, RIPEMD‑160, BLAKE2, SipHash).

Non‑cryptographic hash algorithms : Offer higher performance but lower security, suitable for scenarios without strict security requirements (e.g., CRC32, MurMurHash3, SipHash).

In addition, there are special "slow" hash algorithms that prioritize security over speed.

MD family algorithms include MD2, MD4, MD5, etc. MD5 is the most common, producing a 128‑bit hash. Even the strongest MD algorithm (MD5) can be cracked via brute‑force or rainbow‑table attacks.

Adding a salt—random data inserted into the password before hashing—makes attacks harder but does not guarantee safety, especially since MD5 suffers from collision vulnerabilities.

For better security, use a strong cryptographic hash algorithm together with a unique per‑user salt (e.g., SHA2, SHA3, SM3). However, even these can be vulnerable to high‑performance cracking hardware.

A more secure approach is to use a Key Derivation Function (KDF), also known as a password‑hashing algorithm. KDFs are intentionally slow, making large‑scale attacks impractical.

Common KDF Algorithms (increasing security)

PBKDF2 : Repeated HMAC iterations; older and less recommended.

Bcrypt : Based on Blowfish, higher security than PBKDF2 but still relatively low memory usage.

Scrypt : Uses more memory, offering higher security; configurable memory and CPU usage.

Argon2 : Winner of the 2015 Password Hashing Competition; memory‑hard and considered the strongest currently.

Spring Security provides implementations of these KDF algorithms:

For most projects, Bcrypt offers a good balance of security and performance.

Bcrypt incorporates a random salt and a configurable cost factor (work factor). The cost determines the computational difficulty; higher values increase resistance to brute‑force attacks.

Spring Security’s

BCryptPasswordEncoder

supports a cost factor range of 4‑31, with a default of 10.

<code>/**
  * @param strength the log rounds to use, between 4 and 31
  */
public BCryptPasswordEncoder(int strength) {
  this(strength, null);
}
</code>