How to Choose a Hash Algorithm for Data Security

Choosing the wrong hash algorithm is one of the most common security mistakes in software, and also one of the easiest to prevent. Developers still store passwords with MD5 out of habit, then wonder why the passwords are cracked as soon as the database leaks. This article is a decision guide: for every common security task, which algorithm is correct, why, and which ones you should avoid.

The key rule to understand up front: there is no single hash algorithm that fits every need. Data security has different requirements for storing passwords, verifying file integrity, and proving data has not been tampered with. Using the right algorithm for the wrong purpose is as dangerous as not hashing at all.

The Basics: Two Families of Hash Algorithms

Before choosing, you need to distinguish between two broad families: fast hashes and slow hashes.

Fast hashes like MD5, SHA-1, SHA-2, and SHA-3 are designed for maximum speed. They are perfect for integrity verification, checksums, and building data structures. The problem is that this speed is exactly what makes them unsuitable for password storage, because an attacker can also compute billions of hashes per second.

Slow hashes like bcrypt, argon2, and PBKDF2 are designed to slow down brute force by running thousands of iterations or consuming significant memory. They are deliberately slow, and that is precisely what makes them right for passwords.

When to Use MD5 and SHA-1

MD5 and SHA-1 are obsolete algorithms, but you cannot ignore them entirely because they still live in many legacy systems.

MD5

MD5 produces 128 bits and is considered fully broken. Collisions (two different inputs with the same hash) can be produced trivially, and this attack has been demonstrated since 2004. Never use MD5 for security: not for passwords, not for important integrity checks, and not for signing data.

When will you still encounter MD5? In legacy systems, database migrations, and some API formats that still use MD5 checksums. When you meet it, treat it as a warning sign. If a third party gives you a file with an MD5 checksum, you can still compute it for compatibility, but schedule a migration to a modern algorithm.

SHA-1

SHA-1 produces 160 bits. In 2017, a team from Google and CWI Amsterdam proved SHA-1 collisions were practical (the SHAttered attack). For all new security purposes, SHA-1 is considered broken.

The only exceptions that still appear are SHA-1 in git for legacy repository integrity and compatibility verification with old systems. If you are building something new, do not pick SHA-1.

When to Use SHA-2 and SHA-3

For integrity verification, checksums, and digital signing, the SHA-2 and SHA-3 families are the modern choices.

SHA-2 (SHA-256, SHA-512)

SHA-256 produces 256 bits and SHA-512 produces 512 bits. Neither has practical collision attacks, and both are the industry standard everywhere. SHA-256 is the most widely recommended hash in the world today, used for TLS certificates, package verification, and file checksums.

How do you choose between SHA-256 and SHA-512? On 64-bit hardware, SHA-512 can be faster than SHA-256 because it operates on 64-bit words, but its output is longer. For most cases, SHA-256 is more than enough, and its shorter output saves storage. SHA-512 is appropriate when you want extra security margin or work on platforms that optimize it.

SHA-3 (SHA3-256, SHA3-512)

SHA-3 is the standard from the Keccak family, designed in 2015 as a structural alternative to SHA-2. It is not more secure than SHA-2, but it is structurally different, so if SHA-2 is ever found weak, SHA-3 remains safe. This is called diversification: two algorithms from different families will not break at the same time.

Which should you choose between SHA-2 and SHA-3? For new projects, both are correct. Follow the standard used by your ecosystem. Many modern standards like TLS 1.3 already support SHA-3, but the wider ecosystem is still dominated by SHA-256. If you have no special reason, SHA-256 is the safe, best-supported choice.

When to Use Hashing for Passwords

This is the most important category, because it involves the most sensitive user data. To store passwords, you must not use MD5, SHA-1, SHA-256, or SHA-512 at all, no matter how large your salt is. Fast hashes can be brute-forced with GPUs in seconds for an 8-character hash.

bcrypt

bcrypt is the default choice most widely used for passwords. It was designed specifically for password hashing, has automatic salting, and an adjustable cost factor so it stays slow as hardware gets faster. The output stores the salt and cost inside the hash string, so you do not need to keep separate parameters.

The 72-byte input limit is a known weakness. For ordinary passwords that is not a problem, but if your application accepts very long passwords, be aware of the limit.

argon2

argon2 is the winner of the 2015 Password Hashing Competition and is considered the most modern choice. It has an argon2id variant that combines resistance to GPU attacks (the i variant) and side-channel attacks (the d variant), and exposes tunable memory, time, and parallelism parameters.

Argon2id is the current recommendation for new projects. If your language's library supports it, choose argon2id, then set about 64 MB of memory and a time parameter that produces roughly 0.5 seconds on your target hardware. If it is not supported, bcrypt is still a good choice.

PBKDF2

PBKDF2 is a key derivation function also commonly used for passwords, and it underpins many standards like WPA2 and FIPS 140. It is not memory-hard, so it is more easily attacked with GPUs than argon2. However, because it is widely used and supported, PBKDF2 is still far better than fast hashes.

Use PBKDF2 if you are bound to a standard that requires it, such as interop with a legacy system or certain certifications. If you are free to choose, argon2id or bcrypt is better.

The Role of Salt and Peppering

Why is hashing alone not enough? Because two users with the same password produce the same hash. An attacker using rainbow tables, precomputed lists of hashes for common passwords, can match them instantly. Salt solves this: adding a unique random value per user before hashing makes identical passwords produce different outputs.

The salt does not need to be secret; it is stored in the database alongside the hash. Its job is to force the attacker to compute a hash for every salt separately, destroying rainbow tables. Every user must have a different salt.

Peppering is an additional secret value stored not in the database but in the server configuration or an HSM. If the database leaks but the server configuration does not, peppered hashes remain unattackable offline. For applications with sensitive data, combining salt and peppering is a wise defense-in-depth layer.

Hashing for Integrity and Signatures

When you verify that a file has not changed, you use a fast hash, not a slow one. The most common example is SRI (Subresource Integrity).

SRI ensures that JavaScript or CSS loaded from a CDN is never swapped for a malicious version. You compute the file's hash, embed it in the integrity attribute on a script or link tag, and the browser rejects any file that does not match.

<script
  src="https://cdn.example.com/app.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous"
></script>

For SRI, use sha-384 or sha-512, because Google encourages longer hashes for integrity. You can generate SRI values with a dedicated SRI hash generator or any hash generator that supports base64 output.

For ordinary file checksums, SHA-256 is sufficient. If you build a system that signs data (such as a JSON Web Signature), you do not use a hash alone but an HMAC (keyed hash) or a digital signature with an algorithm like RSA or ECDSA. Here, hashes like SHA-256 or SHA-512 become internal components rather than standalone choices.

A Quick Decision Matrix

Verifying Hashes Correctly

Choosing the right algorithm is only half the work. You also have to compute the hash correctly. A common mistake when verifying downloaded files is comparing the hash of a string instead of the actual file, or forgetting to normalize the format (hex vs base64).

Use a multi-algorithm generator like multiple hash generator to see MD5, SHA-1, SHA-256, and SHA-512 from the same input at once, so you can compare against published values. To verify a file, use a tool that computes the hash directly from the file on your device, and make sure the published hash is in the same format you compare.

When verifying passwords or checksums, always use constant-time comparison. Ordinary string comparison stops earlier when the first character differs, and that timing difference can be exploited to guess values. Functions like hash_equals in PHP or crypto.timingSafeEqual in Node exist for this reason.

Final Recommendations

To summarize, here are the practical rules you can carry into your next project:

• Passwords: argon2id if available, bcrypt otherwise. Add automatic salt and optional peppering.
• File integrity: SHA-256. Sufficient, safe, and supported everywhere.
• CDN SRI: SHA-384 or SHA-512.
• Sensitive data in transit: combine a fast hash with an HMAC and a key.
• MD5 and SHA-1: avoid for all new security work; deal with them only for legacy compatibility.

Most importantly, never postpone migrating away from obsolete algorithms. Every day your system uses MD5 or SHA-1 for security is a day your database is at risk of being cracked cheaply. With this guide, you already know where to move.