📜 Password Policy Generator

🎯 Compliance preset

Select a curated compliance baseline. Form fields below repopulate when you switch presets.

📏 Length

NIST SP 800-63B §5.1.1.2 mandates that verifiers SHOULD permit at least 64 characters. Capping at 16 actively harms security.

🔤 Character class requirements

NIST 2017 update discourages composition rules in favor of length + breach screening. The tool warns when complexity rules are stacked.

🚫 Forbidden patterns

🔄 Rotation & MFA

NIST 2017 update discourages periodic rotation unless evidence of compromise. PCI DSS v3.x requires 90 days — kept for audit compatibility.

🔒 Lockout & Session

📝 Additional organisational rules

🧪 Live regex tester

✅ PASSES policy regex
❌ FAILS policy regex
Enter a candidate password to test.

⚡ Entropy estimate

{{ entropy.minEntropyBits }} bits
{{ entropy.classification }}
Breakdown by character class:
  • {{ c.name }} ({{ c.size }} chars)

Algorithm strength rating: 🔴 Weak — single GPU cracks in hours. Increase length. 🟡 Adequate — slows offline cracking; acceptable for low-value accounts. 🟢 Strong — impractical for typical attackers. 🔵 Overkill — matches modern cryptographic keys.

📝 Policy document (Markdown)

{{ markdown || '# Toggle options on the left to generate a policy.' }}

🌐 Rendered HTML preview

🔣 Validator regex (PCRE-compatible)

{{ regex || '(toggle options to build the regex)' }}

⚠️ The compiled regex is not valid in browser JS — Apache / nginx PCRE may still accept it.

🗂️ JSON Schema (Draft 2020-12)

{{ jsonSchemaText || '{}' }}
{{ activeConfigSnippet || '(no snippet available)' }}

⚠️ Policy warnings

  • {{ w }}
⚠️

ℹ️ About Password Policy Generator

What this tool produces

The Password Policy Generator translates your security team's intent (compliance baseline, MFA requirements, lockout thresholds, rotation cadence) into two parallel artifacts: a human-readable policy document for the InfoSec wiki / ISMS Statement of Applicability, and machine-readable configuration snippets an engineer can paste into nginx, .htaccess, Active Directory Fine-Grained Password Policy (PSO), Kubernetes ValidatingAdmissionPolicy, IAM systems, or any other validator that takes a regex / JSON Schema.

Everything is built from a single source of truth (the form on the left), so the prose policy and the regex / JSON Schema / platform configs cannot drift from each other.

Compliance standards referenced

  • NIST SP 800-63B — Digital Identity Guidelines, Authentication & Lifecycle Management. §5.1.1.2 (memorized secret verifier), §5.2.2 (rate-limiting / lockout), §5.2.5 (verifier impersonation resistance).
  • OWASP ASVS v4.0.3 §2.1 — Password Security Requirements. The 2.1.x control family is the de-facto industry baseline for application-level password policy.
  • PCI DSS v4.0 §8.3 — Identification and Authentication of Users. §8.3.6 (12-char length + alphabetic + numeric), §8.3.7 (no reuse of last 4), §8.3.4 (lockout after 10 invalid attempts).
  • ISO/IEC 27001:2022 Annex A.5.17 — Authentication information.
  • HIPAA Security Rule §164.308(a)(5)(ii)(D) — Password Management.

Why NIST dropped composition rules

The 2017 update to NIST SP 800-63B explicitly removed the long-standing requirement that passwords mix uppercase + lowercase + digits + symbols. Two empirical findings drove the change:

  • Composition rules cause users to converge on highly predictable patterns (Password1!, Summer2024!) that are weaker against rule-based brute-forcing than a long passphrase would be.
  • Empirical password-cracking research (Weir et al., 2010; Carnegie Mellon password studies) shows that length contributes far more entropy than the diversity of character classes used.

Modern guidance is: long passwords (12+ characters, ideally passphrases), screened against a breached-password deny-list, with no composition rules. This tool will warn when you enable composition rules, but it still emits them — you may be implementing a policy for a regulated environment where PCI DSS or an outdated framework mandates them.

Entropy classification

The entropy estimate is the Shannon worst-case: length × log₂(alphabet size) — the upper bound an attacker faces if the user picks uniformly at random from the declared character set. Real human-chosen passwords cluster in non-uniform ways, so this is the ceiling, not the realistic floor.

  • Weak (< 50 bits) — a single modern GPU can exhaust the keyspace in hours. Status: Insufficient.
  • Adequate (50–75 bits) — slows down offline cracking; still bounded by Moore's law. Status: Acceptable for low-value accounts.
  • Strong (75–100 bits) — impractical for any attacker without nation-state resources. Status: Recommended.
  • Overkill (> 100 bits) — matches modern cryptographic keys. Status: More than required for memorized secrets.

Hash storage requirements

Whatever policy you generate here, the verifier must store passwords using a salted, memory-hard one-way function. The policy document explicitly enumerates the approved algorithms (Argon2id, scrypt, bcrypt, PBKDF2) and forbids reversible storage. Unsalted hashes (MD5, SHA-1, SHA-256, SHA-512) are cryptographically broken for password storage — they are designed to be fast, which is the opposite of what you want here.

Source references

API Usage Example:

POST /api/tools/security/password-policy-generator
Content-Type: application/json

{
    "operation": "generate",
    "input": {
        "minLength": 12,
        "requireUppercase": true,
        "requireLowercase": true,
        "requireDigit": true,
        "requireSymbol": false,
        "disallowCommonPasswords": true,
        "mfaRequired": true
    }
}
Ready