What this tool does
Answer a handful of questions about how your system actually stores and protects passwords — hashing algorithm, cost parameters, salting, MFA, breach-checking, and login rate limiting — and get each one graded against OWASP's Password Storage Cheat Sheet and NIST SP 800-63B, the same reference standards and numeric thresholds used elsewhere on this site.
This is a self-assessment, not an inspection of real data — nothing you enter here proves anything about your actual system, and nothing is sent anywhere. If you have an actual password hash you want inspected directly, use Password Hash Inspector instead.
Practices, not policy rules
This tool covers how passwords are technically protected — the hashing algorithm and its parameters, salting, MFA, breach-checking, and rate limiting. It doesn't cover policy rules like minimum length, rotation, or composition requirements — those are what Password Policy Generator and Password Policy Validator check, against the same NIST SP 800-63B standard.
Why salting alone doesn't rescue a fast hash
A unique per-password salt is necessary but not sufficient. It defeats precomputed rainbow tables and stops identical passwords from producing identical hashes — real, meaningful protection. But it does nothing to slow down an attacker who already has the password database and is trying candidate passwords directly: a general-purpose fast hash like SHA-256 or MD5 can still be computed billions of times per second on modern GPU hardware, salted or not. That's the entire reason dedicated password-hashing algorithms (Argon2id, bcrypt, scrypt) exist — they're deliberately slow and, for the memory-hard ones, deliberately expensive to parallelize on GPUs, in a way a general-purpose hash function was never designed to be.
Why MFA, breach-checking, and rate limiting all show up here too
A password-hashing algorithm only matters once an attacker already has the database — it slows down offline cracking. It does nothing against an attacker who doesn't have the database: unlimited online guessing (stopped by rate limiting/lockout), a password reused from another breach (stopped by breach-checking, ideally before it's ever hashed), or a correctly guessed password used alone (stopped by MFA). A perfect hashing algorithm paired with none of these still leaves real, common attack paths wide open.
FAQ
Is anything I enter here sent anywhere?
No — every answer and the resulting assessment stay entirely in your browser.
I don't know my system's exact cost parameters
Check your hashing library's configuration or a recently generated hash directly — Password Hash Inspector decodes an actual bcrypt, Argon2, or PBKDF2 hash and reports its real parameters, rather than requiring you to already know them.
My algorithm isn't listed
This covers Argon2id, bcrypt, scrypt, PBKDF2, and the unsalted-fast-hash/plaintext cases that come up most often in real systems and real security reviews. An algorithm like SHA-3 or BLAKE2 used as a general-purpose (non-password-specific) hash falls into the same category as SHA-256 here — fast and unsuitable for password storage regardless of which specific fast hash it is.
Why does bcrypt/scrypt/PBKDF2 not need a separate salt question?
Standard implementations of bcrypt, scrypt, Argon2id, and PBKDF2 all generate and embed a random salt automatically as part of the algorithm — there's no manual step to accidentally skip. The salt question only applies to general-purpose fast hashes (SHA-256, MD5), where salting is a separate, easy-to-forget step the developer has to implement themselves.