Slow KDFs: bcrypt, scrypt, and Argon2

Salting defeats precomputation but not a targeted guess-and-check attack; a fast hash still lets an attacker try billions of candidates per second. Slow key derivation functions fix that by making each guess deliberately expensive and tunable, cutting an attacker's rate by many orders of magnitude. These are what you should store passwords with.

Salting kills precomputed tables, but it does nothing about raw speed. A fast hash like can be computed billions of times per second on a GPU, so a weak password still falls to a targeted attack even when salted.

The idea

Replace the fast hash with a key derivation function that has a tunable work factor. Making a single guess cost, say, 10 milliseconds instead of 10 nanoseconds is roughly a million-fold slowdown for the attacker, while adding an unnoticeable delay to a legitimate login.

The options

bcrypt has a cost factor that sets the number of iterations. It is mature and widely supported, though it truncates long inputs.

scrypt adds a memory-hardness parameter, so an attacker using custom hardware or GPUs gains less, because memory is expensive to parallelize.

Argon2, specifically Argon2id, is the current recommendation and the winner of the Password Hashing Competition. It lets you tune time, memory, and parallelism independently.

PBKDF2 is iteration-based and acceptable where compliance is required, but it is not memory-hard, so it resists GPUs less well than the others.

Tuning

Choose a target wall-clock cost per hash on your own hardware and set the parameters to hit it, then raise the work factor over time as hardware gets faster. (the Open Worldwide Application Security Project) publishes current starting parameters for each algorithm.

The combination is what matters: a unique salt to defeat precomputation, plus a slow, tuned (key derivation function) to make every remaining guess expensive.

Cost parameters are a promise about hardware that changes

A work factor chosen in 2015 is not the same defence in 2026 against the same money. Cost parameters age, and unlike a certificate they do not expire and nothing alerts you.

The failure is silent by construction: hashes created with an old factor keep verifying correctly forever, so an application can be running a decade-old cost setting with no error, no warning and no visible symptom.

Two practical consequences. Store the parameters with the hash — the standard formats do — so old and new can coexist while you migrate. And re-hash on successful login, when you briefly hold the plaintext, which is the only moment an upgrade is possible without asking users to do anything.