Password Policy Generator

The Password Policy Generator turns a few choices into a complete, consistent password policy — expressed both as plain-English rules for your documentation and as a JSON config your authentication system can consume. It is useful for security teams writing an internal standard or engineers wiring up a sign-up form.

How it works

You start from a preset (Basic, Standard, or Strict) or build a custom policy. Each policy captures the settings real auth systems enforce:

1. Length — a minimum and maximum character count.
2. Character classes — independent toggles for lowercase, uppercase, number, and symbol requirements.
3. History and expiry — how many previous passwords are blocked from reuse, and whether passwords expire after a set number of days.
4. Lockout — how many failed attempts trigger a lock and for how long.

The tool then renders a bulleted human-readable summary and the equivalent JSON, keeping the two views perfectly in sync as you adjust any field.

What each preset assumes and why

The three presets reflect different risk tolerances and user populations:

Basic — 8-character minimum, at least one number required, no expiry, no reuse history, no lockout. This is a low-friction baseline appropriate for low-risk applications where abandoned accounts are a bigger risk than brute-force attacks. It does not meet modern security standards for anything sensitive.

Standard — 12-character minimum, all four character classes required (lowercase, uppercase, number, symbol), 90-day expiry, last 5 passwords blocked, account locked after 10 failed attempts for 30 minutes. This matches what most enterprise security auditors expect as a baseline for business applications. The 90-day expiry is included for compliance reasons despite current guidance discouraging it (see below).

Strict — 16-character minimum, all four character classes, no scheduled expiry (compliant with NIST guidance), last 24 passwords blocked, lockout after 3 attempts for 60 minutes. This level is appropriate for privileged accounts, admin panels, and high-risk applications where a breach would be severe.

Length versus complexity: what current guidance says

NIST Special Publication 800-63B (the most widely cited modern password standard) takes a clear position: length is the more important factor, and mandatory complexity rules (requiring symbols, uppercase, numbers) do more harm than good in practice.

The reason is behavioural. Mandatory complexity pushes users toward predictable patterns: Password1!, Winter2024$, P@ssw0rd. These satisfy four-class requirements but are easy to guess with a dictionary attack. A 16-character passphrase like correct-horse-battery-staple is longer, harder to crack, and easier to remember.

The current guidance (where practical):

• Prefer long minimum length over mandatory character classes
• Screen against known-breached passwords (services like Have I Been Pwned provide an API for this)
• Disable mandatory periodic expiry unless there is evidence of compromise — expiry forces users toward weaker incremental passwords (Winter2024$ → Spring2024$)
• Allow all printable characters including spaces

The Standard preset includes expiry because many compliance frameworks still require it. Set expiry to 0 in the Custom option if your security framework allows the NIST approach.

The JSON output field by field

The JSON config mirrors every setting in machine-readable form:

{
  "minLength": 12,
  "maxLength": 128,
  "requireLowercase": true,
  "requireUppercase": true,
  "requireNumbers": true,
  "requireSymbols": true,
  "disallowReuseLast": 5,
  "expiryDays": 90,
  "maxFailedAttempts": 10,
  "lockoutMinutes": 30
}

Load this directly into your auth layer or use it as the source of truth for the human-readable policy text, keeping documentation and implementation in sync.