"Password security" isn't one problem — it's four separate layers, each with its own failure mode, its own best practice, and its own tool on this site. A strong password picked by a user does nothing if the server stores it with SHA-256. A properly hashed password does nothing if the policy still forces rotation every 90 days, pushing people toward Summer2024! → Fall2024!. This guide is the map connecting all four — short on its own, linking out to a full deep-dive wherever one already exists on this site.
Four separate layers, not a pipeline you build once in order — each gets its own section below, since each has its own failure mode independent of the others.
Layer 1: Creating a good password
The single biggest lever is length, not complexity. A 16-character random password beats an 8-character one stuffed with symbols, even though the symbol-stuffed one feels more secure — this is the core reversal in current guidance versus the composition-rule advice most people grew up with. The other reversal: a password you can remember is, definitionally, one with structure an attacker (or a tool like this one) can exploit. The reliable fix isn't a cleverer mnemonic — it's not needing to remember it at all.
- Password Generator creates a strong, random credential using the Web Crypto API — the right default when nothing about the password needs to be memorable.
- Password Entropy Calculator checks how an existing password actually holds up, including a scan for the weak patterns (leetspeak substitutions, keyboard runs, sequential runs) a raw entropy number misses.
- Password Cracking Time Estimator runs the same brute-force math from a hypothetical length and character set, for planning a requirement rather than auditing one specific password.
Layer 2: The policy an organization sets
NIST SP 800-63B is the current authoritative standard here, and it's well known for reversing a lot of older conventional wisdom: no mandatory rotation without evidence of compromise, no mandatory character-composition rules, an 8-character hard floor with 15+ recommended, at least 64 characters supported, paste must be allowed (it's how password managers work), and — the one NIST actively requires rather than just permits — new passwords must be checked against a list of known-breached and commonly-used passwords before they're accepted.
- Password Policy Generator turns a set of choices into a policy document and checks each one live against NIST SP 800-63B.
- Password Policy Validator runs the same check the other direction — paste an existing policy's text and it flags what NIST recommends against.
Layer 3: How it's actually stored
This is where the most damage happens when it's wrong, because a storage mistake compromises every password in the database at once, not just one account. Plaintext is the worst case — total exposure the instant a database leaks. A general-purpose fast hash like SHA-256 or MD5 is only marginally better: modern GPUs compute billions of guesses per second against it, salted or not, because it was built for speed, not resistance. The correct tool is a deliberately slow, purpose-built password-hashing algorithm — Argon2id, bcrypt, scrypt, or PBKDF2 specifically when FIPS-140 compliance is a hard requirement.
- Hash Comparison puts all five side by side on speed, security, memory hardness, and recommended use — the fastest way to see why the real KDFs beat a raw hash, and how they differ from each other.
- Password Hash Generator computes bcrypt, Argon2id/i/d, scrypt, and PBKDF2 hashes with configurable parameters, and Password Hash Inspector decodes an existing hash back into its cost factor, salt, and parameters.
- Bcrypt Cost Calculator benchmarks real hashing time to help pick a cost factor, and Bcrypt Capacity Planner turns that into the aggregate server load across your actual user base.
For the full mechanics behind each algorithm, see Password Hashing Explained, Bcrypt vs Argon2, Argon2 Explained, scrypt Explained, PBKDF2 Explained, Why SHA-256 Should Not Be Used for Passwords, and Understanding Salt and Pepper.
Layer 4: Defense beyond the password itself
A perfect hashing algorithm only helps 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 or account lockout), a password reused from another site's breach (stopped by the breach-checking Layer 2 requires), or a correctly guessed password used entirely alone (stopped by requiring a second factor). None of these substitute for the others — a system needs all of them, not whichever one felt most important to implement first.
Password Storage Checker grades exactly these practices together — hashing algorithm, cost parameters, salting, MFA, breach-checking, and rate limiting — against OWASP and NIST guidance in one pass.
The one-paragraph checklist
- Generate passwords randomly; never enforce composition rules on user-chosen ones.
- Set an 8-character floor (15+ recommended), no forced rotation, paste allowed.
- Check every new password against a known-breach list before accepting it.
- Hash with Argon2id (default), bcrypt, or scrypt — never a raw SHA-256/MD5, never plaintext.
- Rate-limit or lock out repeated failed logins.
- Require MFA — it's the one control that catches a correctly guessed password.
FAQ
Where should I actually start?
If you're auditing an existing system rather than building a new one, start with Password Storage Checker — it covers Layers 3 and 4 together in a single pass and will surface the most consequential gaps first.
Is any of this specific to one programming language or framework?
No — everything here is about the concepts and standards (NIST SP 800-63B, OWASP's Password Storage Cheat Sheet), not a specific library. The tools linked throughout compute real values (entropy, hash output, cost-factor timing) entirely in your browser, so they work the same regardless of what your production stack looks like.
Do I need to read all nine linked posts to understand this?
No — this guide is deliberately the short version. Each linked post goes deep on exactly one piece (one algorithm, one comparison, one mechanism); read this one for the map, and follow a link only for the piece that's actually relevant to what you're working on.
Try it yourself
Every tool mentioned above lives in one of two toolkits — Password Security Toolkit for creation, entropy, policy, and storage-practice grading, and Hashing Toolkit for the hashing algorithms themselves, benchmarking, and capacity planning. All of it runs entirely in your browser; nothing you type or paste is ever sent anywhere.