Vulnerability library  /  Weak passwords
CWE-521OWASP A07:2021 Identification and Authentication Failures

Weak password policy

Weak passwords

A weak password policy permits short, common, compromised, or repeatedly guessed passwords. Attackers can exploit it through password spraying, credential stuffing, online guessing, or offline cracking after a data breach.

Also known as
Insufficient password policy · Weak credential requirements · Poor password controls
Typical severity · Medium to High
Last updated
On this page: What it is
  1. 1 · What it is
  2. 2 · Why it matters
  3. 3 · Examples
  4. 4 · How to fix it
  5. 5 · How to test for it
  6. References
  7. Related

What it is#

Password policy includes creation requirements, compromised-password screening, storage, rate limiting, reset, and change behavior. A policy is weak when it permits passwords likely to be guessed or makes strong passwords unnecessarily difficult to use.

Modern guidance emphasizes length, breached-password blocklists, password managers, and online throttling. Predictable composition rules such as requiring one uppercase letter, one number, and one symbol often produce predictable variations rather than strong secrets.

Password strength cannot compensate for missing MFA, insecure recovery, plaintext storage, or unlimited guessing. These controls must work together.

Why it matters#

  • Password spraying across many accounts using a small set of common passwords.
  • Credential stuffing with passwords exposed by unrelated services.
  • Faster offline cracking when password hashes are stolen.
  • Reuse of default or organization-specific passwords.
  • Account takeover of privileged, remote-access, email, and cloud accounts.
  • Increased help-desk and recovery abuse when periodic changes encourage predictable patterns.
Typical severity

Usually medium. High when weak passwords protect privileged accounts, externally accessible administration, remote access, sensitive data, or systems without MFA and effective rate limiting. Actual severity depends on context: who is affected, what data or actions are reachable, and existing controls.

Examples#

✕ Vulnerablejavascript
// Vulnerable: short length and superficial character rules.
function passwordAllowed(password) {
  return password.length >= 8 &&
    /[A-Z]/.test(password) &&
    /[0-9]/.test(password) &&
    /[^A-Za-z0-9]/.test(password);
}
✓ Fixedjavascript
// Fixed: length plus a compromised/common-password blocklist.
async function passwordAllowed(password, username) {
  const normalized = password.normalize('NFC');
  const length = [...normalized].length;

  if (length < 15 || length > 128) return false;
  if (normalized.toLocaleLowerCase().includes(username.toLocaleLowerCase())) return false;
  if (await passwordBlocklist.contains(normalized)) return false;
  return true;
}

The blocklist lookup should use a privacy-preserving local dataset or approved service design and must never log the candidate password.

How to fix it#

1. Require adequate length. NIST SP 800-63B requires at least 15 characters for passwords used as a single authentication factor and permits a minimum of eight when the password is always part of MFA. A uniform 15-character minimum is simpler for many organizations.

2. Allow long passphrases. Support at least 64 characters, spaces, Unicode, paste, autofill, and password managers. Avoid silent truncation.

3. Block common and compromised choices. Compare the entire proposed password against a blocklist containing common, breached, expected, and context-specific values such as the product or organization name.

4. Avoid arbitrary composition and periodic-change rules. Do not require predictable mixtures of character classes. Require a change after evidence of compromise, not merely because a calendar interval elapsed.

5. Rate-limit authentication. Apply account-aware throttling, progressive delays, bot detection, and alerting. Avoid controls that let an attacker permanently lock out arbitrary users.

6. Add phishing-resistant MFA. Prefer passkeys or hardware-backed WebAuthn for privileged and high-risk access. Password policy alone does not stop phishing or reuse.

7. Store passwords with a dedicated password-hashing function. Use a unique random salt and a tuned Argon2id configuration, or an approved alternative appropriate to the platform. Keep any pepper in a managed secret or key service.

8. Secure reset and enrollment. Reset tokens must be random, short lived, single use, and invalidated after use. Notify the user of credential changes without revealing secrets.

9. Remove defaults. Force unique initialization for service, appliance, and administrator credentials. Do not ship a shared initial password.

How to test for it#

  • Review registration, password change, reset, administrator provisioning, API-created users, and imported accounts for consistent enforcement.
  • With approved test accounts, try short, common, breached, username-derived, product-derived, and previously used passwords.
  • Confirm long passphrases, spaces, Unicode, paste, autofill, and password-manager generated values work correctly.
  • Verify passwords are not truncated in the UI, API, identity provider, or hashing layer.
  • Test rate limits across account, source, device, and distributed attempts without causing production account lockouts.
  • Review password-hash format and work factors using synthetic accounts; never extract real user passwords for testing.
  • Verify reset and administrator-assisted changes invalidate appropriate sessions and generate audit events.
  • Add automated policy tests so alternate enrollment paths cannot bypass the same rules.

References#

Permalinklibrary.infinity8labs.com/weak-password-policy/JSON
Found this in Breachvane? Your finding links here for background. Evidence, affected assets and retest status are in your Breachvane ↗ (opens in a new tab) workspace. Need help fixing it? Talk to us.