Password Strength Checking for Developers: Libraries and Implementation

Developers building authentication systems face two related but distinct problems: checking whether a password is strong enough to accept, and storing it securely. This guide covers the strength-checking side — which libraries to use, what rules to enforce per NIST and OWASP, and how a visual tool can help you validate that your implementation handles edge cases correctly.

Client-Side Password Strength Libraries

The most widely used JavaScript password strength library is zxcvbn, originally developed by Dropbox. Unlike checkers that count character types, zxcvbn uses pattern matching against common password patterns, dictionaries, keyboard sequences, and dates — producing a score from 0-4 and estimated crack times.

Key characteristics:

• Entropy-based scoring with pattern recognition (not just character count)
• Estimates crack time against online throttled, online unthrottled, and offline attack scenarios
• Returns human-readable feedback strings for UI display
• Available as npm package: zxcvbn
• Large bundle size (~800KB) — consider lazy loading

Alternative libraries worth evaluating:

• password-strength-meter — lighter, simpler, configurable rules
• OWASP Passfault — Java-based, enterprise-focused, detailed pattern analysis
• pwned — checks a password hash prefix against the HIBP API (k-anonymity model — safe to use)

For most web apps, zxcvbn for client-side UX feedback and a server-side HIBP check on submission is the recommended combination.

What NIST SP 800-63B Actually Requires Developers to Implement

NIST SP 800-63B (Digital Identity Guidelines) specifies what authentication systems should check at password creation and change time:

• Minimum length: 8 characters for user-chosen passwords; up to 64 characters must be accepted
• No composition rules: Do not require specific character types (uppercase, symbols) — these drive predictable patterns
• Screen against breached lists: Check submitted passwords against known-breached password databases. Reject and prompt the user to choose another if found.
• No hints or knowledge-based authentication: Deprecated
• No mandatory expiration: Only require change when compromise is suspected
• No complexity rules: No more "must contain 1 uppercase, 1 number, 1 symbol"

The practical implementation for the breached-password check: use the HIBP Pwned Passwords API with k-anonymity (send only first 5 chars of the SHA-1 hash of the password, never the full hash or plain text). This is free to use, well-documented, and privacy-preserving.

Sell Custom Apparel — We Handle Printing & Free Shipping

OWASP Rules for Password Storage (Separate from Strength)

Strength checking happens at input time. Storage security is a separate concern handled server-side. The OWASP Password Storage Cheat Sheet recommendations:

• Hash algorithm: bcrypt, scrypt, or Argon2id — any of these is acceptable. Argon2id is the current recommended choice where supported.
• Work factor: bcrypt cost factor 10+ (adjust up as hardware improves); Argon2id with OWASP recommended parameters
• Salt: Modern hashing libraries (bcrypt, Argon2) automatically generate a cryptographically secure random salt per password — do not implement salting manually
• Never: MD5, SHA-1, or unsalted hashes for password storage
• Never: Encrypt passwords (symmetric encryption is reversible; hashing is one-way)
• Never: Store plaintext passwords for any reason including "password hints"

The combination: zxcvbn for client-side UX, HIBP k-anonymity check on server-side submission, Argon2id for storage. This covers the full lifecycle.

Using a Visual Strength Checker to Test Your Implementation

During development, a visual strength checker is useful for validating that your implementation behaves correctly on edge-case inputs that are harder to catch in automated tests:

• Does your system reject "password" and "123456" as expected?
• Does it correctly handle Unicode characters (emoji, non-Latin scripts)?
• Does a very long password (64+ characters) work without truncation?
• Does it correctly score a password that meets all character-type requirements but is short (e.g., "aB1!")? This should still score weak.
• Does it correctly score a 20-character lowercase-only password? Despite missing character types, length alone should push it into Medium or Strong territory.

The Wolf Password Strength Checker can serve as a reference implementation for testing edge cases during development. It uses the same entropy calculation and pattern detection as production-quality checkers — type any candidate password and compare the score against what your implementation returns. Discrepancies often surface implementation bugs in character counting or pattern detection logic.

Frequently Asked Questions

What is the best JavaScript library for password strength checking?

zxcvbn (by Dropbox) is the most widely used. It scores passwords 0-4 using pattern matching against common passwords, keyboard sequences, dictionary words, and dates — producing more accurate results than simple character counting. It returns estimated crack times and human-readable feedback for UI display.

Should I enforce character complexity rules in my app?

NIST SP 800-63B says no. Mandatory complexity rules (must have uppercase, symbol, number) lead to predictable patterns like "Password1!" that are weak despite meeting the requirements. Better approaches: enforce minimum length (8+ characters), screen against breached password lists, and use a strength meter for user feedback without hard blocking.

How do I safely check passwords against the HIBP breached database?

Use the HIBP Pwned Passwords API with k-anonymity: hash the password with SHA-1 client-side, send only the first 5 characters of the hash to the API, and receive back all matching hash suffixes. Compare locally to check for a match. This approach never sends the full password or hash to any server. The API is free and well-maintained.

What hashing algorithm should I use for password storage?

Argon2id is the current OWASP-recommended choice. bcrypt (cost factor 10+) and scrypt are also acceptable. Never use MD5, SHA-1, or SHA-256 alone — these are too fast for password hashing and lack the work factor that makes brute force impractical. Use a well-maintained library rather than implementing hashing manually.