👨‍💻
Application Security Handbook
  • Application Security Handbook
  • Web Application
    • Authentication
      • Authentication with Login and Password
      • Authentication with Phone Number
      • OAuth 2.0 Authentication
      • Multi-factor Authentication
      • Default Passwords
      • Password Change
      • Password Policy
      • Password Reset
      • Password Storage
      • One Time Password (OTP)
      • Email Address Confirmation
    • Authorization
    • Concept of Trusted Devices
    • Content Security Policy (CSP)
    • Cookie Security
    • Cryptography
      • Cryptographic Keys Management
      • Encryption
      • Hash-based Message Authentication Code (HMAC)
      • Hashing
      • Random Generators
      • Universal Unique Identifier (UUID)
    • Error and Exception Handling
    • File Upload
    • Input Validation
    • JSON Web Token (JWT)
    • Logging and Monitoring
    • Output Encoding
    • Regular Expressions
    • Sensitive Data Management
    • Session Management
    • Transport Layer Protection
    • Vulnerability Mitigation
      • Brute-force
      • Command Injection
      • Cross-Site Request Forgery (CSRF)
      • Cross-Site Scripting (XSS)
      • Mass Parameter Assignment
      • Parameter Pollution
      • Path Traversal
      • Regular Expression Denial of Service (ReDoS)
      • SQL Injection (SQLi)
      • XML External Entity (XXE) Injection
Powered by GitBook
On this page
  • Overview
  • General
  1. Web Application
  2. Authentication

Password Policy

PreviousPassword ChangeNextPassword Reset

Last updated 1 year ago

Overview

This page contains a recommended example of a password policy.

General

  • Password length from 12 characters to 64 characters.

  • Use user-provided passwords as is. Do not truncate spaces or other special characters.

  • Prevent the use of passwords that contains dictionary words and compromised passwords during registration, login, and password change.

  • Create a wordlist of breached passwords and check passwords against it. You can use the following wordlists to create a custom one:

  • Do not use password composition rules limiting the type of characters.

  • Do not set requirements for upper or lower case, numbers or special characters.

  • Do not use periodic credential rotation or password history requirements.

  • Use a third-party service (that provides a zero-knowledge proof API) to validate passwords against breached ones.

    • Make sure plain text passwords are not sent or used in verifying the breach status of a password.

  • Allow using Unicode characters in passwords. Consider a single Unicode code as a character. In other words, 12 emoji should be a valid password.

  • Notify users if they use a breached password during sign-in. For example, you can send a notification email with the link to the password change page.

https://github.com/danielmiessler/SecLists
https://github.com/Dormidera/WordList-Compendium
https://github.com/ignis-sec/Pwdb-Public
https://github.com/ihebski/DefaultCreds-cheat-sheet