Secure Password Rules

Passwords are still one of the most common ways users authenticate to websites and applications. A strong password is not simply a password that contains uppercase letters, numbers, and symbols. Modern password security depends primarily on length, unpredictability, uniqueness, secure storage, and protection against automated guessing.

The most important rule is simple: a password should be difficult for an attacker to guess and should not be reused across different services. Using a password manager and generating passwords with a cryptographically secure random source can make these requirements much easier to follow.

Secure Password Rules at a Glance

1. Password Length Matters

Length is one of the strongest practical factors in password security. Each additional character can increase the number of possible combinations, especially when characters are selected randomly.

For a randomly generated password with an alphabet of N possible characters and a length of L, the theoretical number of possible combinations is N raised to the power of L.

Possible combinations = N^L

N = size of character set
L = password length

For example, increasing a randomly generated password from 8 characters to 16 characters does much more than simply doubling its difficulty. The search space grows exponentially when the same character set is used.

2. Prefer Long Passwords Over Complicated Short Ones

A short password containing many character types can still be easier to guess than a substantially longer password. Attackers do not necessarily try every possible combination in arbitrary order. They use dictionaries, leaked passwords, rules, patterns, and specialized guessing strategies.

3. Randomness Is More Important Than Appearance

A password does not become secure simply because it looks complicated. Humans naturally create patterns. Replacing letters with similar-looking numbers, adding a symbol at the end, or capitalizing the first character often produces predictable structures.

password
   ↓
Password
   ↓
Password1
   ↓
Password1!
   ↓
Password1!2026

These transformations may look increasingly complex to a person, but attackers commonly account for such patterns in password-guessing tools.

4. Use a Cryptographically Secure Random Generator

When generating passwords automatically, use a cryptographically secure random number generator rather than a conventional pseudorandom generator intended for simulations or games.

A CSPRNG is designed to make its output computationally difficult to predict. This is important because a password generator is only as strong as the randomness used to select its characters.

Secure entropy
      ↓
CSPRNG
      ↓
Random character selection
      ↓
Password

Avoid using timestamps, usernames, counters, predictable seeds, or other easily known values as the primary source of randomness for passwords.

5. Make Every Password Unique

Password reuse creates a chain reaction. If an attacker obtains your password from one breached website, they can try the same email address and password combination against other services.

Service A breached
       ↓
Email + password exposed
       ↓
Attacker tries same credentials
       ↓
Service B
Service C
Service D
       ↓
Multiple accounts compromised

A unique password for every important account limits the damage caused by a single credential leak.

6. Use a Password Manager

Remembering a different long random password for every website is impractical for most people. A password manager solves this problem by securely storing credentials and generating unique passwords when needed.

• Generate long random passwords.
• Store unique credentials for different services.
• Reduce password reuse.
• Fill credentials automatically.
• Help identify duplicate or weak passwords.
• Make changing compromised passwords easier.

The password protecting the password manager itself becomes especially important. It should be strong, unique, and protected with additional authentication where available.

7. Avoid Common Passwords

Attackers commonly begin password guessing with large lists of known passwords. These lists can contain passwords collected from previous breaches, common words, popular patterns, and frequently used combinations.

• password
• 123456
• qwerty
• admin
• letmein
• welcome
• company names
• season + year combinations

A password that appears in a breach database should be considered unsafe even if it looks sufficiently complicated.

8. Avoid Personal Information

Names, birthdays, phone numbers, pet names, addresses, favorite teams, and other personal information can be used to build targeted password guesses.

Name + birth year
Pet name + number
Company + year
Favorite team + season

↓
Predictable password candidates

Public information is particularly dangerous because attackers can gather it from social media, company websites, public records, and previous data leaks.

9. Avoid Predictable Modifications

Changing a compromised password from Summer2025! to Summer2026! does not provide the same protection as creating an entirely new random password. Attackers can test systematic variations of known credentials.

10. Password Complexity Rules Are Not the Whole Story

Traditional password policies often required uppercase letters, lowercase letters, numbers, and special characters. These requirements can be useful in some contexts, but they do not automatically make a password strong.

For example, a predictable password that satisfies every character-category requirement can still be vulnerable to dictionary and pattern-based guessing.

Length, uniqueness, and unpredictability should be treated as fundamental properties rather than relying exclusively on a checklist of character types.

11. Passphrases Can Be a Good Option

A passphrase is a password made from multiple words. When the words are selected randomly from a sufficiently large word list, a passphrase can provide substantial entropy while remaining easier to remember than a random string.

random word
+
random word
+
random word
+
random word
+
random word

The key word is randomly. A sentence or phrase chosen by a person may contain predictable language patterns and therefore should not automatically be considered equivalent to a randomly generated passphrase.

12. Understand Password Entropy

Entropy is a useful way to reason about the number of possible password values. For an ideal uniformly random password selected from N possible characters and having length L, the theoretical entropy is approximately L × log2(N) bits.

Entropy ≈ L × log2(N)

L = password length
N = number of possible characters

This calculation assumes uniform random selection. Human-created passwords usually do not satisfy that assumption, which is why a password's visible complexity can be misleading.

Example: Why Randomness Changes the Calculation

Consider two passwords with the same length. One is selected randomly from a large character set, while the other is a familiar phrase modified with a number and symbol. They may have the same number of characters, but their effective security can be very different because the second password is constrained by human behavior and predictable patterns.

13. Hashing Does Not Make a Weak Password Strong

Password hashing is a server-side storage mechanism, not a method for improving password quality. A server should never need to store users' plaintext passwords. Instead, passwords should be processed with a password hashing scheme designed for credential storage.

However, hashing a weak password does not increase the password's original entropy. If an attacker can guess the original password, the resulting hash can still be matched.

Weak password
      ↓
Password hashing
      ↓
Stored password hash

The hash protects storage,
not the password's original strength.

14. Password Hashing and Fast Hash Functions

General-purpose cryptographic hash functions are designed to be fast. That property is useful for many applications but undesirable for password storage because attackers can also perform large numbers of guesses quickly.

Password storage should therefore use a dedicated password hashing or password-based key derivation function with appropriate work factors and parameters. Examples include Argon2id, scrypt, bcrypt, and PBKDF2.

15. Salted Password Hashes

A salt is a unique random value associated with a password hash. It prevents identical passwords from producing identical stored hashes and makes precomputed lookup attacks substantially less useful.

Password + unique salt
          ↓
Password hashing function
          ↓
Stored hash + salt

A salt does not need to be secret, but it should be unique and generated appropriately. Modern password hashing libraries generally handle salt generation as part of the password-hashing process.

16. Never Store Plaintext Passwords

A properly designed authentication system should not store users' plaintext passwords. If a database containing plaintext credentials is compromised, every stored password can immediately be exposed.

Password hashes with appropriate password-hashing parameters provide an additional barrier because attackers must perform password guesses against the stored hashes.

17. Protect Password Reset Flows

A strong password does not help if an attacker can easily bypass it through an insecure password-reset mechanism. Recovery tokens should be generated using secure randomness, have appropriate expiration, and be invalidated after use.

• Generate reset tokens with a CSPRNG.
• Use sufficiently large random values.
• Give tokens a limited lifetime.
• Invalidate tokens after successful use.
• Avoid exposing tokens in logs.
• Rate-limit recovery attempts.

18. Use Multi-Factor Authentication

Multi-factor authentication adds another layer of protection beyond the password. Depending on the implementation, the additional factor can help protect an account even when the password has been leaked or guessed.

For high-value accounts, enabling MFA is one of the most useful improvements available in addition to using unique strong passwords.

19. Do Not Share Passwords

Passwords should generally be treated as private credentials. Sending passwords through ordinary chat messages, email, or unprotected documents can expose them to additional systems and people.

When multiple people need access to a service, use appropriate account-sharing or organizational access controls instead of sharing a personal password whenever possible.

20. Do Not Log Passwords

Applications should avoid writing passwords, authentication tokens, reset links, or other credentials into application logs. Logs are often accessible to developers, monitoring systems, support tools, and third-party services.

User submits password
        ↓
Authentication system
        ↓
Verify securely

Avoid:
password → application log
password → analytics
password → debug output

21. Rate Limiting Matters

Even strong passwords benefit from server-side protections against automated guessing. Login endpoints should generally include appropriate rate limiting, monitoring, and abuse detection.

A password's strength and the authentication system's resistance to automated attacks work together. Neither should be treated as a replacement for the other.

22. Do Not Rely on Security Through Obscurity

A password should remain secure even if an attacker knows the password-generation method. Security should come from the secret value itself and the strength of the underlying cryptographic design, not from hiding how the password was produced.

23. How Long Should a Password Be?

There is no single length that makes every password secure because security depends on how the password was created and how the service protects authentication. A randomly generated password and a human-selected password of the same length can have very different effective entropy.

24. Avoid Forced Periodic Password Changes

Forcing users to change passwords on a fixed schedule can encourage predictable modifications, password reuse, and weaker passwords. A better approach is to require changes when there is evidence of compromise or another legitimate security reason.

Organizations should also screen newly chosen passwords against lists of known compromised or extremely common passwords.

25. Check for Compromised Passwords

A password can be strong in theory but still unsafe if it has already appeared in a breach. Services should prevent or discourage the use of known compromised credentials, while users should replace passwords that have been exposed.

A password should be considered compromised even if the affected website is not one that you currently use. Reusing that password elsewhere can create additional risk.

Password Rules for Developers

• Store passwords using a dedicated password hashing algorithm.
• Use a unique salt for every password.
• Allow sufficiently long passwords.
• Avoid unnecessary restrictions on legitimate password characters.
• Reject known compromised passwords where appropriate.
• Use secure random generation for reset tokens.
• Rate-limit authentication attempts.
• Protect authentication endpoints from automated abuse.
• Never log plaintext passwords.
• Support MFA.

Password Rules for Users

• Use a unique password for every important service.
• Prefer long random passwords.
• Use a password manager.
• Enable MFA whenever available.
• Do not use personal information in passwords.
• Do not reuse passwords from old accounts.
• Replace passwords exposed in breaches.
• Do not share passwords unnecessarily.
• Protect your password manager account.
• Use a secure recovery method.

Secure Password Checklist

☐ Long enough for the intended risk
☐ Generated or selected unpredictably
☐ Unique to this service
☐ Not based on personal information
☐ Not a common or breached password
☐ Stored in a password manager when appropriate
☐ MFA enabled when available
☐ Recovery methods protected
☐ Never logged or shared unnecessarily

Common Password Security Mistakes

• Using the same password everywhere.
• Using a short password because it contains symbols.
• Adding the current year to an old password.
• Using a pet's name or birthday.
• Using Math.random() for security-sensitive password generation.
• Saving passwords in plain text files.
• Sending passwords through insecure communication channels.
• Using a generic hash function as the only password-storage mechanism.
• Ignoring compromised-password warnings.
• Skipping MFA on high-value accounts.

Frequently Asked Questions

Useful Security Tools

The Password Generator can create strong random passwords, while the Entropy Calculator can help estimate the theoretical size of a password's search space. The Secure Random Generator is useful when you need cryptographically secure random values. Hash Generator can be useful for understanding hash functions, while API Key Generator can create random credentials for applications and services.

Conclusion

Secure password practices are less about creating increasingly complicated-looking strings and more about reducing predictability. Long, unique, randomly generated passwords provide a strong foundation, especially when they are stored in a password manager.

For developers, password security also depends on secure password hashing, unique salts, rate limiting, protected recovery flows, and MFA support. For users, the most effective habits are simple: never reuse important passwords, avoid predictable personal information, use secure random generation, and enable additional authentication factors whenever possible.