MD5, SHA-256, bcrypt, Argon2 Choosing the Right Hash for the Job

Pick the wrong hashing algorithm for the job and you’re either leaking user passwords or wasting engineering effort on overkill. MD5, SHA-256, bcrypt, Argon2 — they all produce a fixed-length output from arbitrary input, but they’re built for completely different purposes. Using SHA-256 to hash passwords is nearly as dangerous as storing them in plain text. Using Argon2 for file checksums is just wasteful. This guide cuts through the noise.

What a Cryptographic Hash Function Actually Does

A hash function takes input of any size and produces a fixed-length digest. Three properties define a cryptographic hash function:

• Deterministic — the same input always produces the same output.
• One-way — you cannot reverse a hash back to the original input without brute-force.
• Avalanche effect — changing a single bit in the input produces a completely different hash.

A good hash function is also collision-resistant: it should be computationally infeasible to find two different inputs that produce the same output. This is where older algorithms have broken down.

MD5: Fast, Broken for Security, Still Useful

MD5 was designed in 1991 and produces a 128-bit (32 hex character) digest. It’s extremely fast — which is both its utility and its fatal flaw.

$ echo -n "hello" | md5sum
5d41402abc4b2a76b9719d911017c592  -

MD5 is cryptographically broken. Researchers demonstrated practical collision attacks in 2004, and by 2008, forged SSL certificates were being created using MD5 collisions. You can generate two different files with the same MD5 hash in seconds on modern hardware.

Where MD5 is still acceptable:

• Non-security checksums — verifying a file was not corrupted in transit when integrity attacks are not a threat model
• Deduplication — comparing large files to detect duplicates in storage systems
• Cache keys — generating short, unique identifiers for cache entries
• Hash table lookups — fast, non-cryptographic use cases in data structures

Where MD5 is absolutely not acceptable: passwords, digital signatures, TLS certificates, or anything where an adversary might craft a collision. Try our Générateur de hachage MD5 to see the output format, but don’t mistake familiarity for safety.

SHA Family: SHA-1 Is Dead, SHA-256 Is the Standard

The Secure Hash Algorithm family was developed by NIST. SHA-1 produces 160-bit output and was the dominant choice through the 2000s. It’s now deprecated — Google demonstrated a practical SHA-1 collision (SHAttered) in 2017, and all major browsers and certificate authorities have dropped it entirely.

SHA-256 et SHA-512 are part of SHA-2 and remain secure. SHA-256 produces 256-bit (64 hex character) output; SHA-512 produces 512-bit (128 hex character) output. Neither has known practical collision attacks.

$ echo -n "hello" | sha256sum
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824  -

$ echo -n "hello" | sha512sum
9b71d224bd62f3785d96d46ad3ea3d73319bfbc2890caadae2dff72519673ca7...  -

Use SHA-256 or SHA-512 for:

• File integrity verification — checksums for software releases, backups, and downloads. Use our Calculateur de hachage de fichier to generate and verify them.
• Signatures numériques — RSA and ECDSA sign the hash of a document, not the document itself. SHA-256 is the standard here.
• HMAC (message authentication) — HMAC-SHA256 authenticates API requests and webhook payloads. Try it with our Générateur HMAC.
• Key derivation (as a component) — PBKDF2 uses SHA-256 internally, though Argon2 has replaced it for most password use cases.

SHA-3 is a separate algorithm family (based on Keccak, not SHA-2) developed as a backup standard. It’s not faster than SHA-2 in software, but provides algorithm diversity. If you need SHA-3 output, our Générateur de Hachage SHA-3 covers all four variants (SHA3-224, SHA3-256, SHA3-384, SHA3-512).

You can experiment with all SHA variants using our Générateur de hachage SHA.

The Password Hashing Problem: Why SHA Is Wrong for Passwords

This is the most important distinction in this entire guide. SHA-256 is fast. That’s great for checksums. It’s a disaster for passwords.

Modern GPUs can compute billions of SHA-256 hashes per second. A 2024-era consumer GPU running optimized software can test over 10 billion SHA-256 hashes per second against a stolen password database. An 8-character password using letters, numbers, and symbols has around 218 trillion possible combinations — that’s about 6 hours of work on a single high-end GPU.

Two attacks make raw SHA even worse:

• Tables arc-en-ciel — precomputed tables mapping common passwords to their hashes. Without a salt, sha256("password123") is always the same hash, and that hash appears in every rainbow table ever built.
• Credential stuffing at scale — once an attacker has your SHA-hashed database, they crack it offline, at their own pace, without triggering any rate limits on your system.

Salting helps with rainbow tables, but not with raw speed. A unique salt per user forces attackers to crack each hash individually — but if SHA-256 can do 10 billion hashes/second, that’s still fast enough to compromise short or common passwords in minutes.

Password hashing needs to be slow by design. That’s why bcrypt and Argon2 exist.

bcrypt: The 25-Year Standard That Still Holds Up

bcrypt was designed in 1999 by Niels Provos and David Mazieres specifically for password hashing. Its key feature is an adjustable cost factor — a work factor that controls how much computation is required to produce a single hash.

// bcrypt with cost factor 12
$2b$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/LeuRTGnLIiBj3b7Cm

// Structure: $2b$ = algorithm, $12$ = cost factor, then 53 chars of salt + hash

At cost factor 12, bcrypt performs 4,096 (2^12) rounds of key setup. On that same GPU that cracks SHA-256 at 10 billion hashes/second, bcrypt at cost 12 drops to around 20,000-30,000 hashes/second. That’s a difference of roughly 300,000x.

As hardware gets faster, you increase the cost factor. Cost 10 was standard in 2010; cost 12 is the common recommendation today; cost 14 is appropriate for high-security applications where login latency is acceptable.

bcrypt has two known limitations:

• 72-byte password truncation — bcrypt silently ignores input beyond 72 bytes. Very long passwords (passphrases) may have less entropy than expected.
• CPU-bound only — bcrypt does not use memory as a hardness parameter. GPUs and ASICs, while slower than SHA on bcrypt, still benefit from parallelism.

Despite these limitations, bcrypt remains a solid default. It’s well-tested, supported in every major language, and better than anything SHA-based. Test bcrypt output with our Générateur de hachage Bcrypt.

Argon2: The Modern Default

Argon2 won the Password Hashing Competition in 2015 after a multi-year, open evaluation process. It’s the current state of the art and is specified in RFC 9106. Unlike bcrypt, it has three tunable parameters: time cost (iterations), memory cost (RAM required), and parallelism (threads).

Argon2 comes in three variants:

• Argon2d — maximizes GPU resistance using data-dependent memory access. Suitable for cryptocurrency and proof-of-work. Vulnerable to side-channel attacks, so not for password hashing in multi-user environments.
• Argon2i — uses data-independent memory access, resistant to side-channel attacks. Was recommended for password hashing, but later analysis showed some weaknesses at lower time costs.
• Argon2id — hybrid of Argon2i and Argon2d. First half uses Argon2i (side-channel resistant), second half uses Argon2d (GPU resistant). This is the one you should use for passwords. RFC 9106 recommends Argon2id as the default.

The RFC 9106 recommended minimum parameters for Argon2id:

# Minimum parameters (interactive logins, latency-sensitive):
m = 19456    # 19 MiB memory
t = 2        # 2 iterations
p = 1        # 1 thread

# Higher security (where latency is acceptable):
m = 65536    # 64 MiB memory
t = 3        # 3 iterations
p = 4        # 4 threads

The memory requirement is the key differentiator. Building an Argon2id cracking rig requires not just fast processors but large amounts of RAM — which is expensive to parallelize compared to raw compute. A system with 1,000 GPU cores cannot all run Argon2id simultaneously if each attempt needs 64 MiB of RAM.

Language support is mature: PHP has password_hash($password, PASSWORD_ARGON2ID) built in since 7.3. Python has the argon2-cffi library. Node.js has argon2 via npm. Go has golang.org/x/crypto/argon2.

Practical Decision Guide

Here’s the short version:

• File checksums / data integrity → SHA-256 (use SHA-512 if you need extra margin). MD5 is acceptable for non-security checksums where collision attacks are not a concern.
• API authentication / webhook signatures → HMAC-SHA256. Never use a bare hash for MACs — HMAC binds the key properly and prevents length extension attacks.
• Signatures numériques → SHA-256 (as the hash input to RSA-PSS or ECDSA). SHA-384 for higher security requirements.
• Mots de passe → Argon2id with at minimum 19 MiB memory and 2 iterations. Fall back to bcrypt at cost 12 if Argon2 is not available in your environment.
• Token generation / session IDs → Don’t hash at all. Use a CSPRNG (crypto.randomBytes in Node.js, secrets.token_hex in Python) to generate 32+ bytes of randomness directly.
• Database deduplication / cache keys → MD5 or SHA-1 are both fine. Speed matters more than collision resistance here.

One common mistake: hashing a password with SHA-256 before passing it to bcrypt to work around the 72-byte limit. Don’t do this — it can reduce the effective entropy of the input and introduce subtle vulnerabilities depending on implementation. If long passphrases matter to you, switch to Argon2id instead.

Référence Rapide

Algorithm   | Output   | Speed      | Use case
------------|----------|------------|----------------------------------
MD5         | 128-bit  | Very fast  | Checksums, dedup, cache keys
SHA-1       | 160-bit  | Fast       | Deprecated — avoid
SHA-256     | 256-bit  | Fast       | File integrity, HMAC, signatures
SHA-512     | 512-bit  | Fast       | Same as SHA-256, larger margin
bcrypt      | 184-bit  | Tunable    | Passwords (legacy systems)
Argon2id    | Variable | Tunable    | Passwords (modern default)

The pattern is simple: general-purpose hashing gets SHA-256; password hashing gets Argon2id. Everything else is a footnote.

Vous aimerez peut-être aussi