Argon2 with too little memory
Memory is what resists GPUs, and raising iterations instead does not compensate
$argon2id$v=19$m=4096,t=3,p=1$c29tZXNhbHQ$RdescudvJCsgt3ub+b+dWRWJTmaaJObG
Password Hash Inspector
Read a bcrypt, Argon2, PBKDF2 or shadow hash and get its actual cost parameters, whether they are adequate today, and the bcrypt limit that silently truncates the password at 72 bytes.
Paste below, or drop a file anywhere on this panel
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Inspect. Nothing leaves this tab.
Formatted
Results
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Examples
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
A bare SHA-256 as a password hash
No salt and no work factor, so one table covers every account
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Reading bcrypt cost as a linear number
It is a power of two. Cost 10 is 1,024 iterations and cost 12 is 4,096, so the gap is four times the attacker cost rather than twenty percent.
Instead:Measure on your own hardware and target roughly 250ms per verification. Twelve is a reasonable floor.
Pre-hashing to hex before bcrypt
bcrypt truncates at 72 BYTES with no error. A SHA-512 hex digest is 128 characters, so half the entropy is silently discarded and two different passwords can verify identically.
Instead:Pre-hash to base64, which fits, or use Argon2id, which has no cap.
Raising Argon2 iterations instead of memory
Iterations scale the attacker cost linearly. Memory scales the hardware they need to parallelise, which is the expensive constraint. High t with low m costs you latency and them very little.
Instead:Raise memory first. Use Argon2id rather than Argon2i for password storage.
The cost parameter is the whole security of a password hash
Every algorithm here is deliberately slow. How slow is a parameter stored in the hash, and a value chosen a few years ago is weaker now than it was then.
bcrypt cost is a power of two
Cost 10 is 1,024 iterations, cost 12 is 4,096, cost 14 is 16,384. Each increment doubles the work, so the difference between 10 and 12 is four times the attacker cost rather than twenty percent more. Twelve is a reasonable floor for new hashes, and the honest way to choose is to measure on your own hardware and aim for roughly 250 milliseconds per verification.
bcrypt silently truncates at 72 BYTES
Anything past 72 bytes is discarded with no error, so two long passwords sharing a 72-byte prefix verify identically. This bites hardest when a system pre-hashes before bcrypt: a SHA-256 hex digest is 64 characters and survives, and a SHA-512 hex digest is 128 and loses half its entropy. Pre-hash to base64 instead, or use Argon2id, which has no such cap. Note bytes rather than characters: a password with accented or CJK characters reaches 72 bytes sooner than it looks.
Argon2 resistance comes from memory, not iterations
This is the most common misconfiguration in the category. Iterations scale an attacker cost linearly; memory scales the hardware they need to parallelise, which is the expensive constraint. High iterations with low memory costs you latency and costs them very little. Raise memory before iterations, and use Argon2id rather than Argon2i for password storage.
The salt lives in the hash, and that is correct
A salt is not a secret. Its job is to make every hash unique so one precomputed table cannot cover many accounts, and it has to be readable to verify a password at all. Storing it in the same field is the design rather than a leak. If you are keeping salts in a separate column you have added complexity for no security benefit.
A bare digest is not a password hash
MD5, SHA-1 and SHA-256 are built to be fast, which is the opposite of what this needs: a commodity GPU computes billions of SHA-256 per second. With no salt, one table covers every account at once. If you find one, the migration is rehash on next successful login: verify against the old value, store an Argon2id hash, drop the old column. That moves the whole estate without forcing a password reset.
What this cannot see
Whether the hash matches any given password, because verifying needs the password and the algorithm implementation. It reads the parameters from the string, in your browser, and sends nothing. It also cannot know your hardware, and the right cost is whatever takes about a quarter of a second on it.
More cryptography tools
Hash Generator MD5 through SHA-512, and which to trust Which Algorithm Should I Use? The right one, and the wrong ones Hash Identifier Length narrows it. Nothing identifies it