Weak Password Requirements - Codepure Documentation

Overview

This vulnerability occurs when an application fails to enforce strong password policies during user registration or password changes. Weak requirements might allow users to set passwords that are:

Too short (e.g., less than 12 characters).
Lacking complexity (e.g., not requiring a mix of uppercase, lowercase, numbers, and symbols).
Commonly used (e.g., “password”, “123456”, “qwerty”).
Related to user context (e.g., username, email, real name).
Previously breached (found in known data breach lists).

Attackers can easily guess or crack weak passwords using dictionary attacks, brute-force, or lists of breached credentials. 💪❌

Business Impact

Allowing weak passwords significantly increases the risk of:

Account Takeover: Attackers can easily guess user passwords, leading to unauthorized access.
Credential Stuffing Success: If users reuse weak passwords across multiple sites, a breach elsewhere makes accounts on your site vulnerable.
Reputational Damage: Users expect applications to enforce basic password security; failing to do so reflects poorly on the application’s security posture.

Reference Details

CWE ID: CWE-521 OWASP Top 10 (2021): A07:2021 - Identification and Authentication Failures Severity: Medium

Framework-Specific Analysis and Remediation

Password policies are usually enforced during user registration and password update operations. Modern frameworks often provide built-in validators or configuration options for setting complexity requirements. Key Remediation Principles:

Enforce Minimum Length: Require passwords to be reasonably long (e.g., 12 characters minimum, longer is better).
Enforce Complexity: Require a mix of character types (uppercase, lowercase, numbers, symbols). NIST guidelines (SP 800-63B) suggest length is more important than forced complexity, but complexity remains a common defense-in-depth measure.
Check Against Common Passwords: Use a blocklist of common passwords (e.g., top 10,000 lists) and reject them.
Check Against Breached Passwords: Integrate with services like “Have I Been Pwned” (HIBP) Pwned Passwords API to check if the chosen password has appeared in known data breaches.
Check Against Contextual Information: Prevent users from using their username, email, name, or application name as their password.
Provide Feedback: Clearly inform users about the password requirements.
Server-Side Enforcement: All password policy checks must be performed server-side. Client-side checks are for usability only.

Framework Context

Using Django’s Authentication system validators (AUTH_PASSWORD_VALIDATORS in settings.py). Flask requires manual implementation or extensions.

Vulnerable Scenario 1: No Validators in Django

# settings.py
# DANGEROUS: AUTH_PASSWORD_VALIDATORS is missing or commented out.
# Django will accept any password, including very weak ones.
# AUTH_PASSWORD_VALIDATORS = [ ... ]

Vulnerable Scenario 2: Manual Check Missing Complexity (Flask)

# forms.py (Flask WTForms example)
from wtforms import Form, StringField, PasswordField, validators

class RegistrationForm(Form):
    username = StringField('Username', [validators.Length(min=4, max=25)])
    password = PasswordField('New Password', [
        validators.DataRequired(),
        # DANGEROUS: Only checks length, not complexity or common passwords.
        validators.Length(min=8)
    ])
# Assume route handler uses this form but performs no further password checks.

Mitigation and Best Practices

Django: Configure AUTH_PASSWORD_VALIDATORS in settings.py with built-in validators (UserAttributeSimilarityValidator, MinimumLengthValidator, CommonPasswordValidator, NumericPasswordValidator). Consider adding custom validators or third-party packages (like django-pwned-passwords) for breached password checks.
Flask: Implement server-side checks in the route handler or user service layer. Check length, complexity (using regex or character class counts), against common password lists, and optionally against the HIBP API.

Secure Code Example

# settings.py (Django - Secure Validators)
# SECURE: Configure a strong set of validators.
AUTH_PASSWORD_VALIDATORS = [
    { # Checks against username, email, first_name, last_name
        'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
    },
    { # Enforces minimum length
        'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
        'OPTIONS': {
            'min_length': 12, # SECURE: Increased minimum length
        }
    },
    { # Checks against a built-in list of common passwords
        'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
    },
    { # Prevents purely numeric passwords
        'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
    },
    # Optional: Add django-pwned-passwords validator here
    # {
    #    'NAME': 'pwned_passwords_django.validators.PwnedPasswordValidator',
    # },
]

# services/auth_service.py (Flask - Secure Custom Validation)
import re
# Assume check_if_common_password and check_if_pwned exist

def is_password_strong(password, username, email):
    if len(password) < 12:
        return False, "Password must be at least 12 characters long."
    # SECURE: Example complexity check (at least 1 upper, 1 lower, 1 digit, 1 symbol)
    if not re.search(r"[A-Z]", password): return False, "Requires uppercase."
    if not re.search(r"[a-z]", password): return False, "Requires lowercase."
    if not re.search(r"\d", password): return False, "Requires digit."
    if not re.search(r"[!@#$%^&*()_+=\-{}\[\]:;\"'|\\<>,.?/~`]", password): return False, "Requires symbol."

    # SECURE: Check against common passwords
    if check_if_common_password(password):
        return False, "Password is too common."

    # SECURE: Check against user context
    if username.lower() in password.lower() or email.split('@')[0].lower() in password.lower():
         return False, "Password cannot contain username or email parts."

    # SECURE: Check against breached passwords (e.g., using HIBP API)
    # if check_if_pwned(password):
    #    return False, "Password has appeared in a data breach."

    return True, "Password meets requirements."

# Flask route handler would call is_password_strong before saving.

Testing Strategy

Attempt to register or change passwords using values that violate the intended policy:

Too short (e.g., “Pass1!”)
Missing complexity (e.g., “passwordpassword”, “123456789012”, “PASSWORDPASSWORD”)
Common passwords (“password”, “123456”, “admin”)
Contextual passwords (username, email prefix, application name) Verify that the server-side validation rejects weak passwords with appropriate error messages. Check Django AUTH_PASSWORD_VALIDATORS setting. Review custom validation logic.

Framework Context

Using Bean Validation (javax.validation.constraints) annotations on DTOs, custom validation logic in services, or Spring Security’s password policy features (less common directly).

Vulnerable Scenario 1: Missing Bean Validation

A UserRegistrationDto doesn’t have annotations to check password complexity.

// dto/UserRegistrationDto.java
public class UserRegistrationDto {
    private String username;
    // DANGEROUS: Only basic length check, if any. No complexity.
    // Needs @Pattern or custom validator.
    @Size(min = 8, message = "Password must be at least 8 characters")
    private String password;
    // ... getters/setters ...
}
// Controller accepts this DTO but relies only on @Size.

Vulnerable Scenario 2: Weak Custom Validation Logic

// service/ValidationService.java
public boolean isPasswordValid(String password) {
    // DANGEROUS: Only checks length.
    if (password == null || password.length() < 8) {
        return false;
    }
    // Missing checks for complexity, common passwords, etc.
    return true;
}

Mitigation and Best Practices

Bean Validation: Use @Size for length and @Pattern with a strong regex for complexity on DTO fields. Implement custom ConstraintValidator classes for more complex rules (like checking against common lists, HIBP, or user context).
Service Layer: Perform validation within the user service before hashing and saving the password.

Secure Code Example

// dto/UserRegistrationDto.java (Secure with Bean Validation)
import javax.validation.constraints.Size;
import javax.validation.constraints.Pattern;
// Assume @NotPwned and @NotCommonPassword are custom constraint annotations

public class UserRegistrationDto {
    @NotNull @Size(min=4) private String username; // Added NotNull
    @NotNull // Added NotNull
    @Size(min = 12, message = "Password must be at least 12 characters long.")
    // SECURE: Regex for complexity (e.g., 1 upper, 1 lower, 1 digit, 1 symbol)
    @Pattern(regexp = "^(?=.*[a-z])(?=.*[A-Z])(?=.*\\d)(?=.*[@$!%*?&])[A-Za-z\\d@$!%*?&]{12,}$",
             message = "Password must contain uppercase, lowercase, digit, and special character.")
    // SECURE: Custom validators (conceptual)
    // @NotCommonPassword
    // @NotPwned
    private String password;
    // ... getters/setters ...
}

// Controller enables validation
// @PostMapping("/register")
// public String register(@Valid @ModelAttribute("user") UserRegistrationDto dto, BindingResult result) {
//     if (result.hasErrors()) { return "register"; }
//     // Proceed if validation passes...
// }

Testing Strategy

Attempt registration/password changes with passwords violating length, complexity, common lists, and contextual rules. Ensure @Valid is used in controllers and DTOs have appropriate @Size, @Pattern, and custom constraint annotations. Verify server-side rejection.

Framework Context

Configuring ASP.NET Core Identity password options in Startup.cs.

Vulnerable Scenario 1: Weak Identity Options

// Startup.cs (ConfigureServices)
services.AddDefaultIdentity<IdentityUser>(options => {
    // DANGEROUS: Configuring weak password requirements.
    options.Password.RequiredLength = 6; // Too short
    options.Password.RequireDigit = false;
    options.Password.RequireLowercase = false;
    options.Password.RequireUppercase = false;
    options.Password.RequireNonAlphanumeric = false;
    options.Password.RequiredUniqueChars = 1; // Very weak complexity
})
.AddEntityFrameworkStores<ApplicationDbContext>();

Vulnerable Scenario 2: Custom Validation Missing Checks

If implementing a custom IPasswordValidator<TUser>, failing to include necessary checks.

// Services/MyCustomPasswordValidator.cs
public class MyCustomPasswordValidator : IPasswordValidator<IdentityUser>
{
    public Task<IdentityResult> ValidateAsync(UserManager<IdentityUser> manager, IdentityUser user, string password)
    {
        // DANGEROUS: Only checks length. Missing complexity, common, contextual checks.
        if (string.IsNullOrEmpty(password) || password.Length < 10)
        {
            return Task.FromResult(IdentityResult.Failed(new IdentityError { /* ... */ }));
        }
        return Task.FromResult(IdentityResult.Success);
    }
}
// And registering this custom validator in Startup.cs
// services.AddIdentity<...>().AddPasswordValidator<MyCustomPasswordValidator>();

Mitigation and Best Practices

Identity Options: Configure IdentityOptions.Password in Startup.cs with strong requirements (e.g., RequiredLength = 12, RequireDigit = true, RequireLowercase = true, RequireUppercase = true, RequireNonAlphanumeric = true).
Custom Validators: If needed, implement IPasswordValidator<TUser> to add checks (e.g., against common lists, HIBP, user context) in addition to Identity’s built-in options. Register multiple validators if necessary.

Secure Code Example

// Startup.cs (ConfigureServices - Secure Identity Options)
services.AddDefaultIdentity<IdentityUser>(options => {
    options.SignIn.RequireConfirmedAccount = true;
    // SECURE: Configure strong password requirements.
    options.Password.RequiredLength = 12;
    options.Password.RequireDigit = true;
    options.Password.RequireLowercase = true;
    options.Password.RequireUppercase = true;
    options.Password.RequireNonAlphanumeric = true;
    options.Password.RequiredUniqueChars = 6; // Example: Higher unique chars
})
// Optional: Add custom validator for breached passwords
// .AddPasswordValidator<PwnedPasswordValidator>() // Assume this class exists
.AddEntityFrameworkStores<ApplicationDbContext>();

Testing Strategy

Attempt registration/password changes violating the configured Identity options (length, digits, upper/lower, non-alphanumeric). Verify rejection by Identity. If custom validators are used, test their specific logic (common passwords, contextual checks, breached passwords).

Framework Context

Using Laravel’s built-in validation rules or writing custom validation logic.

Vulnerable Scenario 1: Missing Validation Rules (Laravel)

A registration request validation doesn’t include strong password checks.

// app/Http/Requests/RegisterRequest.php
public function rules()
{
    return [
        'name' => ['required', 'string', 'max:255'],
        'email' => ['required', 'string', 'email', 'max:255', 'unique:users'],
        // DANGEROUS: Only checks length and requires confirmation.
        // No complexity, common password, or breached checks.
        'password' => ['required', 'string', 'min:8', 'confirmed'],
    ];
}

Vulnerable Scenario 2: Weak Plain PHP Check

<?php
// register.php
$password = $_POST['password'];
// DANGEROUS: Minimal check, allows weak passwords.
if (strlen($password) < 6) {
    die("Password must be at least 6 characters.");
}
// No other checks performed before hashing and saving.
// ... hash password and save user ...
?>

Mitigation and Best Practices

Laravel: Use built-in validation rules like Password::min(12)->mixedCase()->numbers()->symbols()->uncompromised() (checks HIBP). Chain rules for length, complexity, and breached status in your Form Request or controller validation.
Plain PHP: Implement robust checks manually: length (strlen), complexity (regex preg_match for character classes), common lists (check against a file/array), contextual checks, and optionally HIBP API.

Secure Code Example

// app/Http/Requests/RegisterRequest.php (Laravel - Secure)
use Illuminate.Validation\Rules\Password; // Import Password rule

public function rules()
{
    return [
        'name' => ['required', 'string', 'max:255'],
        'email' => ['required', 'string', 'email', 'max:255', 'unique:users'],
        // SECURE: Use the robust Password rule object.
        'password' => ['required', 'confirmed',
            Password::min(12) // Minimum length
                ->mixedCase() // Requires upper and lower case
                ->numbers()   // Requires numbers
                ->symbols()   // Requires symbols
                ->uncompromised(), // Checks Have I Been Pwned DB (requires internet)
        ],
    ];
}

<?php
// register_secure.php (Plain PHP - Secure Checks)
$password = $_POST['password'];
$username = $_POST['username']; // Assume exists

// SECURE: Combine multiple checks
if (strlen($password) < 12) die("Min 12 chars.");
if (!preg_match('/[A-Z]/', $password)) die("Requires uppercase.");
if (!preg_match('/[a-z]/', $password)) die("Requires lowercase.");
if (!preg_match('/\d/', $password)) die("Requires digit.");
if (!preg_match('/[^A-Za-z0-9]/', $password)) die("Requires symbol."); // Basic symbol check
if (is_common_password($password)) die("Password too common."); // Assume function exists
if (str_contains(strtolower($password), strtolower($username))) die("No username in password.");
// if (is_pwned($password)) die("Password found in breach."); // Assume function exists

// ... proceed to hash and save ...
?>

Testing Strategy

Attempt registration/password changes violating the defined Laravel validation rules or custom PHP checks (length, complexity, common, contextual). Verify server-side rejection. Use known breached passwords to test the uncompromised() rule if implemented.

Framework Context

Using validation libraries like express-validator, joi, or custom logic in route handlers or services.

Vulnerable Scenario 1: `express-validator` Missing Complexity

// routes/auth.js
const { body, validationResult } = require('express-validator');

router.post('/register',
    body('email').isEmail(),
    // DANGEROUS: Only validates length.
    body('password').isLength({ min: 8 }),
    (req, res) => {
        const errors = validationResult(req);
        if (!errors.isEmpty()) {
            return res.status(400).json({ errors: errors.array() });
        }
        // ... proceed with registration ...
    }
);

Vulnerable Scenario 2: Weak Manual Regex

// services/userService.js
function validatePassword(password) {
    // DANGEROUS: Simple regex only checks for length and maybe one char type.
    const weakRegex = /.{8,}/; // Example: Just length
    if (!password || !weakRegex.test(password)) {
        throw new Error("Password does not meet requirements.");
    }
    // Missing other checks...
}

Mitigation and Best Practices

express-validator: Chain multiple validators: isLength({ min: 12 }), .matches(/[A-Z]/).withMessage(...), .matches(/[a-z]/).withMessage(...), etc. Use .custom() validators for complex checks (common list, HIBP, context).
joi: Define strong rules using Joi.string().min(12).pattern(...).
Manual: Implement robust checks for length, complexity (multiple regex), common lists, context, and potentially HIBP.

Secure Code Example

// routes/auth.js (Secure with express-validator)
const { body, validationResult } = require('express-validator');
const { checkPasswordNotInCommonList, checkPasswordNotPwned } = require('../validators/custom'); // Assume custom validators

router.post('/register-secure',
    body('email').isEmail().normalizeEmail(),
    body('username').isLength({ min: 3 }).trim().escape(),
    // SECURE: Chained validation rules
    body('password')
        .isLength({ min: 12 }).withMessage('Must be 12+ chars')
        .matches(/\d/).withMessage('Must contain a digit')
        .matches(/[A-Z]/).withMessage('Must contain uppercase')
        .matches(/[a-z]/).withMessage('Must contain lowercase')
        .matches(/[^A-Za-z0-9]/).withMessage('Must contain a symbol')
        .custom((value, { req }) => { // Check context
            if (value.toLowerCase().includes(req.body.username?.toLowerCase())) {
                 throw new Error('Password cannot contain username');
            } return true;
        })
        .custom(checkPasswordNotInCommonList) // Custom validator
        // .custom(checkPasswordNotPwned) // Optional HIBP check
        ,
    body('passwordConfirmation').custom((value, { req }) => {
        if (value !== req.body.password) { throw new Error('Passwords do not match'); } return true;
    }),
    (req, res) => {
        const errors = validationResult(req);
        if (!errors.isEmpty()) {
            return res.status(400).json({ errors: errors.array() });
        }
        // ... proceed with registration ...
    }
);

Testing Strategy

Attempt registration/password changes violating the configured rules (length, complexity via regex, custom checks). Verify server-side rejection with appropriate messages. Test common and contextual passwords.

Framework Context

Using Active Record validations in models or custom validation logic.

Vulnerable Scenario 1: Weak Active Record Validation

# app/models/user.rb
class User < ApplicationRecord
  has_secure_password # Handles hashing, but not policy enforcement by itself

  # DANGEROUS: Only validates length on password (via has_secure_password's default
  # presence check) or a simple length validation.
  validates :password, length: { minimum: 8 }, if: -> { new_record? || !password.nil? }
  # No complexity, common, contextual, or breached checks.
end

Vulnerable Scenario 2: Devise without Strong Password Extension

Standard Devise enforces length but requires extensions (like devise-security) for more advanced policies.

# app/models/user.rb (Using Devise default)
class User < ApplicationRecord
  devise :database_authenticatable, :registerable,
         :recoverable, :rememberable, :validatable # :validatable checks length/presence

  # DANGEROUS: Default :validatable might only check length (e.g., 6-8 chars).
  # No complexity, common password, etc., checks included by default.
end

Mitigation and Best Practices

Active Record: Add custom validate methods or use validates_format_of with strong regex for complexity. Implement checks against common lists, context (username, email), and optionally HIBP API.
Devise: Configure password length (config.password_length in devise.rb). Add gems like devise-security to enable more policies (complexity, breached passwords via HIBP).

Secure Code Example

# app/models/user.rb (Secure Active Record Validations)
class User < ApplicationRecord
  has_secure_password

  # SECURE: Define strong validation rules
  validates :password, length: { minimum: 12 }, if: -> { new_record? || !password.nil? }
  validate :password_complexity
  validate :password_not_common
  validate :password_not_contextual
  # validate :password_not_pwned # Optional custom validation

  private

  def password_complexity
    # return if password.blank? || password =~ /^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[^A-Za-z0-9]).{12,}$/
    # More readable checks:
    return if password.blank?
    errors.add :password, 'must include uppercase' unless password =~ /[A-Z]/
    errors.add :password, 'must include lowercase' unless password =~ /[a-z]/
    errors.add :password, 'must include digit' unless password =~ /\d/
    errors.add :password, 'must include symbol' unless password =~ /[^A-Za-z0-9]/
  end

  def password_not_common
     # Assume COMMON_PASSWORDS is a loaded Set
     errors.add :password, 'is too common' if password.present? && COMMON_PASSWORDS.include?(password)
  end

  def password_not_contextual
      return if password.blank? || email.blank?
      errors.add :password, 'cannot contain email' if password.downcase.include?(email.downcase)
      # Add checks for username, name etc.
  end
  # Implement password_not_pwned using HIBP API if desired
end

# config/initializers/devise.rb (Secure Devise Configuration)
Devise.setup do |config|
  # ==> Password Length
  # SECURE: Increase minimum password length.
  config.password_length = 12..128

  # Add devise-security gem configurations here for complexity, HIBP etc.
  # config.min_password_complexity = { digit: 1, lower: 1, upper: 1, symbol: 1 }
  # config.pwned_password_check_enabled = true
  # ... other devise-security options ...
end

Testing Strategy

Attempt registration/password changes violating the Active Record validations or Devise configuration (length, complexity, etc.). Verify server-side rejection. Test common, contextual, and (if implemented) known breached passwords.

Getting Started

Product Guides

Integrations

Supported Languages

Vulnerability Reference

Security & Trust

User Management

Documentation Index

​Overview

​Business Impact

Reference Details

​Framework-Specific Analysis and Remediation

​Framework Context

​Vulnerable Scenario 1: No Validators in Django

​Vulnerable Scenario 2: Manual Check Missing Complexity (Flask)

​Mitigation and Best Practices

​Secure Code Example

​Testing Strategy

​Framework Context

​Vulnerable Scenario 1: Missing Bean Validation

​Vulnerable Scenario 2: Weak Custom Validation Logic

​Mitigation and Best Practices

​Secure Code Example

​Testing Strategy

​Framework Context

​Vulnerable Scenario 1: Weak Identity Options

​Vulnerable Scenario 2: Custom Validation Missing Checks

​Mitigation and Best Practices

​Secure Code Example

​Testing Strategy

​Framework Context

​Vulnerable Scenario 1: Missing Validation Rules (Laravel)

​Vulnerable Scenario 2: Weak Plain PHP Check

​Mitigation and Best Practices

​Secure Code Example

​Testing Strategy

​Framework Context

​Vulnerable Scenario 1: express-validator Missing Complexity

​Vulnerable Scenario 2: Weak Manual Regex

​Mitigation and Best Practices

​Secure Code Example

​Testing Strategy

​Framework Context

​Vulnerable Scenario 1: Weak Active Record Validation

​Vulnerable Scenario 2: Devise without Strong Password Extension

​Mitigation and Best Practices

​Secure Code Example

​Testing Strategy

Overview

Business Impact

Framework-Specific Analysis and Remediation

Framework Context

Vulnerable Scenario 1: No Validators in Django

Vulnerable Scenario 2: Manual Check Missing Complexity (Flask)

Mitigation and Best Practices

Secure Code Example

Testing Strategy

Framework Context

Vulnerable Scenario 1: Missing Bean Validation

Vulnerable Scenario 2: Weak Custom Validation Logic

Mitigation and Best Practices

Secure Code Example

Testing Strategy

Framework Context

Vulnerable Scenario 1: Weak Identity Options

Vulnerable Scenario 2: Custom Validation Missing Checks

Mitigation and Best Practices

Secure Code Example

Testing Strategy

Framework Context

Vulnerable Scenario 1: Missing Validation Rules (Laravel)

Vulnerable Scenario 2: Weak Plain PHP Check

Mitigation and Best Practices

Secure Code Example

Testing Strategy

Framework Context

Vulnerable Scenario 1: `express-validator` Missing Complexity

Vulnerable Scenario 2: Weak Manual Regex

Mitigation and Best Practices

Secure Code Example

Testing Strategy

Framework Context

Vulnerable Scenario 1: Weak Active Record Validation

Vulnerable Scenario 2: Devise without Strong Password Extension

Mitigation and Best Practices

Secure Code Example

Testing Strategy