Should I use PBKDF2, bcrypt, scrypt, or Argon2id?

Argon2id is the modern best choice (OWASP 2023): memory-hard, defeats GPU acceleration, won the 2015 Password Hashing Competition. Use Argon2id with parameters m=19MB, t=2, p=1. If Argon2id isn't available, scrypt (memory-hard) is the next best. bcrypt is well-vetted but capped at 72-byte passwords (silent truncation gotcha) and not memory-hard. PBKDF2 is the 'still acceptable' choice when nothing else is available — it's NIST-approved but the easiest to GPU-accelerate. Never use raw MD5, SHA-1, SHA-256, or SHA-512 for passwords; they're designed to be fast.

How many PBKDF2 iterations should I use?

OWASP 2023: PBKDF2-SHA256 with 600,000 iterations, or PBKDF2-SHA512 with 210,000. NIST 800-63B (2017) minimum is 10,000 — that's now considered weak. Tune to your application's latency budget: most users tolerate 250-500ms login delay. The benchmark above shows your machine's specific cost at each iteration count; if 600K iterations adds <300ms to login, use it. For administrative or high-security accounts, push higher. Don't use under 100K; that's the absolute floor for any serious system in 2026.

What does '60 bits of entropy' mean for a password?

60 bits = 2^60 ≈ 1.15 quintillion possible passwords. Achieved by: 12 random alphanumeric chars (lowercase + uppercase + digits = 62 pool, log2(62)×12 = ~71 bits, so 12 chars exceeds 60). 5 random words from a 7,776-word diceware list = log2(7776)×5 = ~64 bits. 10 random characters from full keyboard (94 pool) = ~65 bits. Below 60 bits: trivially crackable offline against weak hashing. 80+ bits: uncrackable against PBKDF2-grade hashing on consumer hardware. 128+ bits: uncrackable forever even on quantum hardware (under reasonable assumptions).

Why is the GPU multiplier different for SHA-256 vs PBKDF2?

Algorithm parallelism. Raw SHA-256 is embarrassingly parallel — a GPU can compute thousands of independent hashes simultaneously. Modern GPUs do ~10^10 SHA-256 hashes/sec (10 billion). PBKDF2 is sequential within each hash (10K iterations applied serially), so per-hash GPU speedup is much smaller, ~10-1000× depending on memory access patterns. Argon2id is memory-hard: the GPU's memory bandwidth becomes the bottleneck, multiplier drops to ~10-100×. This is the entire point of memory-hard KDFs.

Are these crack-time estimates pessimistic or optimistic?

Conservative. Real-world considerations that shift estimates: (1) Botnets and large clusters increase attacker compute by 100-10,000× over a single GPU. (2) Specialized hardware (FPGAs, ASICs) is 10-100× faster than GPUs on raw SHA-256, similar on PBKDF2. (3) Cloud GPU rental ($0.50-3/hr per A100) makes brute force cheap for high-value targets. (4) Smart attackers don't brute-force uniformly — they try common passwords, dictionary attacks, and password-spraying first, which can crack 30-50% of passwords without exhaustive search. The numbers here represent UNIFORM brute force; intelligent attacks are faster on weak/common passwords but slower than uniform on truly random ones.

How does this benchmark compare to bcrypt cost factor 12?

bcrypt at cost factor 12 takes ~250-400ms on modern CPUs — comparable to PBKDF2 SHA-256 at ~600K iterations. Cost factor 14 takes ~1-1.5s — pushing user-perceptible latency. Argon2id at OWASP defaults takes ~100-200ms but with much greater GPU resistance. We can't measure bcrypt directly here (not in Web Crypto), but published benchmarks from the bcrypt authors and pen-test firms (Hashcat) put GPU acceleration at ~10K-100K bcrypt-cost-12 hashes/sec — roughly 100-1000× single-thread CPU. Conclusion: at equal user-latency, Argon2id > bcrypt > scrypt > PBKDF2 for password-cracking resistance.

Developer Utilities · Free tool

Password Hash Benchmark

Q: What does '60 bits of entropy' mean for a password?

60 bits = 2^60 ≈ 1.15 quintillion possible passwords. Achieved by: 12 random alphanumeric chars (lowercase + uppercase + digits = 62 pool, log2(62)×12 = ~71 bits, so 12 chars exceeds 60). 5 random words from a 7,776-word diceware list = log2(7776)×5 = ~64 bits. 10 random characters from full keyboard (94 pool) = ~65 bits. Below 60 bits: trivially crackable offline against weak hashing. 80+ bits: uncrackable against PBKDF2-grade hashing on consumer hardware. 128+ bits: uncrackable forever even on quantum hardware (under reasonable assumptions).

Q: Why is the GPU multiplier different for SHA-256 vs PBKDF2?

Algorithm parallelism. Raw SHA-256 is embarrassingly parallel — a GPU can compute thousands of independent hashes simultaneously. Modern GPUs do ~10^10 SHA-256 hashes/sec (10 billion). PBKDF2 is sequential within each hash (10K iterations applied serially), so per-hash GPU speedup is much smaller, ~10-1000× depending on memory access patterns. Argon2id is memory-hard: the GPU's memory bandwidth becomes the bottleneck, multiplier drops to ~10-100×. This is the entire point of memory-hard KDFs.

Q: Are these crack-time estimates pessimistic or optimistic?

Conservative. Real-world considerations that shift estimates: (1) Botnets and large clusters increase attacker compute by 100-10,000× over a single GPU. (2) Specialized hardware (FPGAs, ASICs) is 10-100× faster than GPUs on raw SHA-256, similar on PBKDF2. (3) Cloud GPU rental ($0.50-3/hr per A100) makes brute force cheap for high-value targets. (4) Smart attackers don't brute-force uniformly — they try common passwords, dictionary attacks, and password-spraying first, which can crack 30-50% of passwords without exhaustive search. The numbers here represent UNIFORM brute force; intelligent attacks are faster on weak/common passwords but slower than uniform on truly random ones.

Q: How does this benchmark compare to bcrypt cost factor 12?

bcrypt at cost factor 12 takes ~250-400ms on modern CPUs — comparable to PBKDF2 SHA-256 at ~600K iterations. Cost factor 14 takes ~1-1.5s — pushing user-perceptible latency. Argon2id at OWASP defaults takes ~100-200ms but with much greater GPU resistance. We can't measure bcrypt directly here (not in Web Crypto), but published benchmarks from the bcrypt authors and pen-test firms (Hashcat) put GPU acceleration at ~10K-100K bcrypt-cost-12 hashes/sec — roughly 100-1000× single-thread CPU. Conclusion: at equal user-latency, Argon2id > bcrypt > scrypt > PBKDF2 for password-cracking resistance.

Measure PBKDF2 + SHA-256 speed via Web Crypto. Live crack-time estimator at any entropy. OWASP iteration recommendations. Downloadable JSON.

Updated May 2026

Detected engine:unknown(hardwareConcurrency: 4)

3 warmup + 7 measured runs per case. Web Crypto SubtleCrypto API.

Choose cases (6 of 7 selected)

SHA-256 (1 iteration)
Raw hash. NOT a password KDF — included as baseline. This is what an attacker hashes per guess on weak schemes.PBKDF2 — 1,000 iterations
Old / weak. NIST SP 800-63B (2017) recommends 10,000+; many systems still use 1K.PBKDF2 — 10,000 iterations
NIST SP 800-63B 2017 minimum. Common Django default circa 2018.PBKDF2 — 100,000 iterations
OWASP 2023 recommendation. Common modern setting.PBKDF2 — 310,000 iterations
OWASP 2023 recommendation for SHA-256. The conservative current best practice.PBKDF2 — 600,000 iterations
OWASP 2023 recommendation for SHA-512. Aggressive — adds noticeable login latency.PBKDF2 — 1,000,000 iterations
Stress level. Login takes ~1+ seconds on most hardware; users complain.

Found this useful?Email

What it does

Measures real password-hashing performance via the browser’s Web Crypto API: SHA-256 raw hash speed, plus PBKDF2 at 7 iteration counts (1K, 10K, 100K, 310K, 600K, 1M). Each measurement on YOUR machine. The interactive crack-time calculator then shows how long an attacker would need to brute-force a password at any entropy level you choose, against each algorithm config.

The single most-asked security question is “how strong is this password?” The answer requires knowing your hash algorithm’s speed plus the password’s entropy. This page measures the speed side on real browsers and lets you plug in entropy. Citation-ready JSON output includes engine, hardware, and methodology metadata.

Embed this tool on your siteShow snippet

Paste this snippet into any page. Loads on-demand (lazy), no tracking scripts, and sized to most dashboards. Replace the height to fit your layout.

<iframe src="https://freetoolarena.com/embed/password-hash-benchmark" width="100%" height="720" frameborder="0" loading="lazy" title="Password Hash Benchmark" style="border:1px solid #e2e8f0;border-radius:12px;max-width:720px;"></iframe>

Embed docs →

Example input & output

Input

Engine: V8 (Chrome)
Warmup: 3 runs / case
Measured: 7 runs / case

Output

SHA-256 (1 iter)        median   0.05 ms  →   ~20,000 hashes/sec single-thread
PBKDF2  10K iter        median   8.2 ms   →      ~120 hashes/sec single-thread
PBKDF2 100K iter        median  82 ms     →       ~12 hashes/sec single-thread
PBKDF2 310K iter        median 254 ms     →      ~3.9 hashes/sec single-thread
PBKDF2 600K iter        median 491 ms     →      ~2.0 hashes/sec single-thread
Crack time @ 60-bit entropy on PBKDF2 310K (GPU attacker @ 1000× browser):
→ ~150 K years.

Numbers vary by hardware. Modern desktop CPUs do ~3-10× more PBKDF2/sec than browser due to AVX-256 acceleration; GPUs do 1,000× more on PBKDF2 and 100,000× more on raw SHA-256.

How to use it

Click 'Run benchmark' to measure all 7 hash configurations on your current browser.
Read the median (ms) per hash and hashes/sec for single-thread browser speed.
Move the entropy slider in the crack-time estimator to see brute-force time at different password strengths.
Compare 'single-thread browser' to 'GPU attacker' columns — the gap shows how much KDF iterations matter.
Click 'Download JSON' to save raw measurements with engine, hardware, and methodology metadata.

How it works

Key takeaways

Raw SHA-256 is 10,000-100,000× faster than PBKDF2 at any reasonable iteration count. NEVER use raw hashes (MD5, SHA-1, SHA-256, SHA-512) for password storage. They’re designed to be fast; that’s exactly what attackers want.
OWASP 2023 recommendations: PBKDF2-SHA256 with 600K iterations, PBKDF2-SHA512 with 210K, or (preferred) Argon2id with m=19MB t=2 p=1. The iteration count matters less than the algorithm choice — Argon2 and scrypt are memory-hard, defeating GPU advantages.
GPU acceleration multiplier varies by algorithm. SHA-256 raw: ~100,000× single-thread CPU. PBKDF2: ~1,000-10,000× (sequential constraint limits parallelism). Argon2id: ~10-100× (memory-hard design defeats GPU memory bandwidth).
User-experience constraint: most users tolerate ~250-500ms login latency. Above 1 second feels broken. PBKDF2 600K hits ~500ms on browser (~150ms on server CPU). Tune iterations to your latency budget, not arbitrarily up.

Methodology

Each case calls crypto.subtle.deriveBits (PBKDF2) or crypto.subtle.digest (SHA-256) on a fixed test password and salt. Same input every run.

3 warmup runs — results discarded. Lets the Web Crypto implementation warm up internal caches. SubtleCrypto is C++ in browsers, so warmup matters less than for JS-side benchmarks, but we keep it for consistency.
7 measured runs — performance.now() wraps each call. Times sorted, median reported. Min/max included for variance.
50ms inter-case delay via setTimeout — lets the event loop unblock between long-running PBKDF2 calls so the page stays responsive.

The crack-time estimator math

Brute-force time = combinations / hashes-per-second. With entropy n bits, combinations = 2^n. Then divide by:

Single-thread browser: hashes/sec measured live above. Realistic for small attacks or proof-of-concept.
GPU attacker (estimated): browser speed × algorithm multiplier. PBKDF2 multiplier is 1,000× (conservative; modern consumer GPUs do 10K× on some PBKDF2 modes). SHA-256 multiplier is 100,000× (a mid-tier RTX 4080 does ~10^11 SHA-256/sec; specialized ASICs do ~10^14 for Bitcoin mining and could be repurposed).

These multipliers are conservative. Real attacker hardware can be faster: large attackers run distributed clusters, and ASICs designed for crypto mining can be repurposed for unsalted SHA-256. For salted PBKDF2, attackers can’t precompute (rainbow tables don’t apply) but can still batch many guesses per password.

Why PBKDF2 isn’t the best choice anymore

PBKDF2 is computationally hard but NOT memory-hard. GPUs and ASICs have plenty of compute and modest memory; PBKDF2 is the easiest password-grade KDF to accelerate. Modern recommendations:

Argon2id (winner of Password Hashing Competition 2015): memory-hard, defeats GPU advantage. OWASP recommendation: m=19MB, t=2, p=1. Available via argon2-browser (WASM) or natively in Node 22+ crypto.scrypt-style API.
scrypt: also memory-hard. Older than Argon2 but well-vetted. OWASP fallback if Argon2id isn’t available.
bcrypt: not memory-hard but extremely well-vetted (1999). Cost factor 12 = ~250ms on modern CPU. Capped at 72-byte passwords (longer inputs are silently truncated — gotcha).
PBKDF2: the “legacy that’s still acceptable” choice. NIST-approved. Use only when Argon2id, scrypt, or bcrypt aren’t available. 600K SHA-256 iterations or 210K SHA-512 iterations as 2026 minimum.

Why we measure PBKDF2 specifically

Web Crypto SubtleCrypto only natively supports PBKDF2. Argon2 / bcrypt / scrypt require WASM libraries (200-500KB) or Node.js modules. Adding 500KB of WASM to a benchmark page would slow page load and make the speed numbers un-representative (WASM is slower than native C++ in browsers). Instead, we measure what’s native and cite published Argon2id numbers for context: Argon2id at OWASP-recommended params runs ~50-150ms per hash on modern CPUs, equivalent to PBKDF2 ~300K-1M iterations on the same hardware, but with much stronger GPU resistance.

Common mistakes when reasoning about password hashing

Quoting raw-hash speeds for KDF systems. “A GPU does 10 billion SHA-256/sec” only applies if your system uses raw SHA-256 (which it shouldn’t). PBKDF2-SHA256 with 600K iterations runs at ~10^4-10^5 hashes/sec on the same hardware.
Ignoring salts. Salts don’t slow down a single-password attack but they prevent rainbow tables and force attackers to crack each password separately. Always salt; use crypto.getRandomValues for the salt.
Choosing iteration count by “sounds high”. Increasing PBKDF2 from 100K to 1M increases attack cost 10× but adds 500-900ms to every login. Tune to your latency budget; 300-600K is the sweet spot for most apps.
Migrating algorithms incorrectly. You can’t re-hash existing passwords without the user logging in. The standard pattern: store new-algorithm hashes alongside old, transparently re-hash at next successful login. Keep both columns until the old is fully phased out.
Trusting offline-attack-time estimates blindly. They assume the attacker has your password hash. The MORE common attack vector is online brute force (rate-limited at the server), credential stuffing (passwords from other breaches), and phishing — all of which bypass KDF speed entirely. KDF strength matters when the database leaks; for online attacks, rate limiting and 2FA matter more.

When to use this tool

Designing the password-storage layer of a new application.
Auditing whether your current PBKDF2 iterations meet OWASP / NIST recommendations.
Computing actual attack-time estimates for a security writeup.
Evaluating whether to migrate from PBKDF2 to bcrypt / Argon2id.

When not to use it

Benchmarking bcrypt or Argon2id directly — those aren't in Web Crypto. We cite published numbers in our notes; for direct measurement you'd need a WASM library or native test harness.
Estimating attacks against modern password managers (Bitwarden, 1Password) — those use specialized KDFs (Argon2id) tuned to slow down even custom hardware. The numbers here apply to PBKDF2-protected systems specifically.
Comparing across different system loads — close other tabs, plug in laptop, run multiple times for a clean reading.

Common use cases

Justifying a PBKDF2 iteration-count increase to a security review board.
Choosing between PBKDF2 / bcrypt / Argon2id for a new authentication system.
Setting login-latency expectations for a security-conscious application.
Demonstrating to a non-technical stakeholder why iteration count matters.
Citing measured KDF speeds in security advisories or pen-test reports.

Frequently asked questions

Should I use PBKDF2, bcrypt, scrypt, or Argon2id?: Argon2id is the modern best choice (OWASP 2023): memory-hard, defeats GPU acceleration, won the 2015 Password Hashing Competition. Use Argon2id with parameters m=19MB, t=2, p=1. If Argon2id isn't available, scrypt (memory-hard) is the next best. bcrypt is well-vetted but capped at 72-byte passwords (silent truncation gotcha) and not memory-hard. PBKDF2 is the 'still acceptable' choice when nothing else is available — it's NIST-approved but the easiest to GPU-accelerate. Never use raw MD5, SHA-1, SHA-256, or SHA-512 for passwords; they're designed to be fast.
How many PBKDF2 iterations should I use?: OWASP 2023: PBKDF2-SHA256 with 600,000 iterations, or PBKDF2-SHA512 with 210,000. NIST 800-63B (2017) minimum is 10,000 — that's now considered weak. Tune to your application's latency budget: most users tolerate 250-500ms login delay. The benchmark above shows your machine's specific cost at each iteration count; if 600K iterations adds <300ms to login, use it. For administrative or high-security accounts, push higher. Don't use under 100K; that's the absolute floor for any serious system in 2026.
What does '60 bits of entropy' mean for a password?: 60 bits = 2^60 ≈ 1.15 quintillion possible passwords. Achieved by: 12 random alphanumeric chars (lowercase + uppercase + digits = 62 pool, log2(62)×12 = ~71 bits, so 12 chars exceeds 60). 5 random words from a 7,776-word diceware list = log2(7776)×5 = ~64 bits. 10 random characters from full keyboard (94 pool) = ~65 bits. Below 60 bits: trivially crackable offline against weak hashing. 80+ bits: uncrackable against PBKDF2-grade hashing on consumer hardware. 128+ bits: uncrackable forever even on quantum hardware (under reasonable assumptions).
Why is the GPU multiplier different for SHA-256 vs PBKDF2?: Algorithm parallelism. Raw SHA-256 is embarrassingly parallel — a GPU can compute thousands of independent hashes simultaneously. Modern GPUs do ~10^10 SHA-256 hashes/sec (10 billion). PBKDF2 is sequential within each hash (10K iterations applied serially), so per-hash GPU speedup is much smaller, ~10-1000× depending on memory access patterns. Argon2id is memory-hard: the GPU's memory bandwidth becomes the bottleneck, multiplier drops to ~10-100×. This is the entire point of memory-hard KDFs.
Are these crack-time estimates pessimistic or optimistic?: Conservative. Real-world considerations that shift estimates: (1) Botnets and large clusters increase attacker compute by 100-10,000× over a single GPU. (2) Specialized hardware (FPGAs, ASICs) is 10-100× faster than GPUs on raw SHA-256, similar on PBKDF2. (3) Cloud GPU rental ($0.50-3/hr per A100) makes brute force cheap for high-value targets. (4) Smart attackers don't brute-force uniformly — they try common passwords, dictionary attacks, and password-spraying first, which can crack 30-50% of passwords without exhaustive search. The numbers here represent UNIFORM brute force; intelligent attacks are faster on weak/common passwords but slower than uniform on truly random ones.
How does this benchmark compare to bcrypt cost factor 12?: bcrypt at cost factor 12 takes ~250-400ms on modern CPUs — comparable to PBKDF2 SHA-256 at ~600K iterations. Cost factor 14 takes ~1-1.5s — pushing user-perceptible latency. Argon2id at OWASP defaults takes ~100-200ms but with much greater GPU resistance. We can't measure bcrypt directly here (not in Web Crypto), but published benchmarks from the bcrypt authors and pen-test firms (Hashcat) put GPU acceleration at ~10K-100K bcrypt-cost-12 hashes/sec — roughly 100-1000× single-thread CPU. Conclusion: at equal user-latency, Argon2id > bcrypt > scrypt > PBKDF2 for password-cracking resistance.

Learn more

Explore more developer utilities tools

100% in-browserNo downloadsNo sign-upMalware-freeHow we keep this safe →