Table of Contents
Why Password Policies Matter
In Linux system administration, password policies control how users create and maintain their passwords. These policies influence how long passwords can be used, how complex they must be, and what happens when users enter wrong passwords. Good policies reduce the risk of compromised accounts without making life impossible for legitimate users.
A password policy on a Linux system is enforced by a combination of configuration files and pluggable authentication modules, known as PAM. You do not need to fully understand PAM internals here, but you should know that changing password rules usually means editing PAM related configuration and shadow password settings.
Strong password policies help protect every user on the system, including the administrator. Weak or absent policies make it much easier for attackers to guess or brute force passwords.
Core Concepts of Password Policies
A Linux password policy typically covers four main areas. These are:
Password aging. How long a password is valid, how soon it can be changed again, and when warnings about expiration begin.
Password complexity. Requirements about password length and the types of characters that must be used.
Account lockout. Rules about what happens when a user repeatedly enters the wrong password.
History and reuse. Whether old passwords can be reused and how many previous passwords are remembered.
Each Linux distribution offers slightly different tools and default configurations, but the underlying ideas are the same. You control both when users must change passwords and how hard those passwords are to guess.
Password Aging and `/etc/shadow`
Linux stores password aging information in the file /etc/shadow. This file is readable only by root and special system processes. Each line corresponds to one user and contains several fields separated by colons. Only some of those fields are relevant to password policies.
Although you will learn about user information files more generally in another chapter, here you need to focus on the aging related values. For any given user, the chage tool lets you view and modify this information without editing /etc/shadow by hand.
To see the current aging policy for a user account, use:
sudo chage -l usernameThis reports values like minimum days between password changes, maximum days before expiry, and warning periods.
Important Aging Parameters
Password aging is controlled by several numeric parameters. chage can set these with flags such as -M, -m, -W, and -I. The -E flag sets the account expiration date, which is separate from password aging.
The most common aging related options are:
-M MAX_DAYS sets the maximum number of days a password is valid.
-m MIN_DAYS sets the minimum number of days that must pass before the user can change the password again.
-W WARN_DAYS sets how many days before expiration the user starts receiving warnings at login.
-I INACTIVE_DAYS sets how many days after the password expires before the account is disabled.
-E EXPIRE_DATE sets a date after which the account itself is no longer usable, regardless of password.
For example, to require that a user changes their password every 90 days, cannot change it again within 1 day, and gets warnings 7 days in advance, you might run:
sudo chage -M 90 -m 1 -W 7 username
If you set a very short maximum password age without giving users a reasonable warning period, they may suddenly find themselves forced to change passwords unexpectedly. Always combine -M with a sensible -W value.
Default Aging Values in `/etc/login.defs`
You can define default password aging rules for new accounts in /etc/login.defs. This file is used by account creation tools and defines system wide defaults. It does not automatically change existing accounts.
The most relevant settings are:
PASS_MAX_DAYS maximum number of days a password is valid for new accounts.
PASS_MIN_DAYS minimum number of days allowed between password changes.
PASS_WARN_AGE number of days before expiration that users are warned.
For instance, you might see:
PASS_MAX_DAYS 99999
PASS_MIN_DAYS 0
PASS_WARN_AGE 7If you want stricter policies for new users, you could adjust these values. For example:
PASS_MAX_DAYS 90
PASS_MIN_DAYS 1
PASS_WARN_AGE 14
After changing /etc/login.defs, new users created with tools that respect this file, such as useradd on many distributions, will inherit these settings. Existing users still keep their current aging values unless you modify them with chage.
Enforcing Password Complexity with PAM
Password complexity rules define how strong a password must be. These rules are enforced at the moment a user sets or changes a password. In modern Linux systems, complexity enforcement is handled by PAM modules such as pam_pwquality or pam_cracklib, depending on the distribution and version.
You do not need to learn PAM in depth in this chapter, but you should understand where complexity requirements are usually configured and what the common options are.
On many distributions, password complexity is controlled by:
/etc/security/pwquality.conf a central configuration file used by the pam_pwquality module.
/etc/pam.d/common-password on Debian based systems, or other password related PAM configuration files on distributions like Fedora or Arch.
The details vary, but the ideas behind the options are similar everywhere.
Common Complexity Requirements
Password complexity policies often control:
Minimum length.
Required character classes, such as upper case letters, lower case letters, digits, and special characters.
Prohibition of simple or dictionary based passwords.
Restriction on similarity to the username or previous passwords.
Using pam_pwquality, you might see options such as:
minlen minimum allowed password length.
dcredit how many digits are required or penalized.
ucredit number of upper case letters.
lcredit number of lower case letters.
ocredit number of other characters, such as punctuation.
difok number of characters in the new password that must be different from the old one.
retry number of attempts a user gets to enter a good password before the operation fails.
Values for the *credit options are a little tricky. Negative values mean requirements, for example dcredit=-1 means at least one digit is required. Positive values give credits that reduce minimum length when that character type is used. Many administrators prefer negative values because they are clearer as direct requirements.
Here is an example snippet you might see in a PAM configuration file:
password requisite pam_pwquality.so retry=3 minlen=12 ucredit=-1 lcredit=-1 dcredit=-1 ocredit=-1This policy requires at least 12 characters, and at least one upper case letter, one lower case letter, one digit, and one special character. Users are allowed three attempts to provide a password that meets these rules during a password change command.
If you set very strict complexity rules and a long minimum length, users may respond by writing passwords down or choosing predictable patterns. A good policy balances security with usability.
Configuring `pwquality.conf`
Instead of putting every option directly on the PAM line, some distributions prefer to keep complexity settings in /etc/security/pwquality.conf. In such a case, the PAM configuration will call pam_pwquality.so with minimal inline options, and pwquality.conf will contain lines like:
minlen = 12
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
difok = 5Editing this file requires root privileges. After changing it, new password changes will be subject to the new rules.
Account Lockout and Failed Login Attempts
Password policies also cover what happens when someone repeatedly enters an incorrect password. Lockout policies reduce the risk of brute force attacks, where an attacker tries many password guesses in a short time.
Lockout behavior is mostly configured through specific PAM modules, commonly pam_faillock on modern distributions or pam_tally2 on some older systems. These modules track failed login attempts on a per user basis and can take action after a defined threshold is reached.
Typical lockout related options include:
Number of failed attempts allowed before lockout.
Duration of the lockout.
Whether to count failures per service or system wide.
Whether to unlock accounts automatically after some time or require manual intervention.
For example, a system might be configured so that after 5 failed attempts, the account is locked for 10 minutes. During that period, password based logins for that user are rejected.
Exact configuration syntax depends on distribution and PAM stack layout, but the concepts are the same.
Lockout rules protect against guessing attacks, but if they are too strict they can be abused to create a denial of service. An attacker could deliberately trigger lockouts for many user accounts. Choose thresholds that deter brute force attacks while limiting the impact of abuse.
Password History and Reuse
Another part of password policy is control over password reuse. Without history rules, a user can alternate between two or three favorite passwords every time the system forces a change. That defeats much of the purpose of regular rotation.
On many systems, password history is enforced by the pam_pwhistory module or by options inside pam_unix itself, depending on the distribution and version.
A typical option is remember, which specifies how many previous passwords are remembered and cannot be reused. For example:
password sufficient pam_unix.so sha512 shadow remember=5This configuration means that when a user changes their password, the new one cannot match any of the last five passwords they used.
The stored hashes of previous passwords are usually kept in the shadow file or related storage, not in plain text. Only root or privileged system processes can access this information.
When you combine history rules with aging, you create a policy where users must choose genuinely new passwords at each required change.
System Wide Versus Per User Policies
Password policies can apply either system wide or per user. Understanding this distinction helps you design and troubleshoot configurations.
System wide defaults are defined in files like /etc/login.defs and the main PAM configuration files under /etc/pam.d. These defaults affect how new accounts are created and how authentication works for all users unless overridden.
Per user aging values can be tuned with chage without touching global defaults. For example, you might require more frequent password changes for administrative accounts than for ordinary users by setting different maximum days.
Per user policies for complexity and history are less common and more difficult to manage, since PAM configuration is usually global. Some sites split services into separate PAM stacks and apply different rules for different login methods or groups of users, but that is more advanced and depends heavily on the distribution and PAM version.
For most small and medium systems, you will primarily configure system wide policies and then use tools like chage to adjust specific accounts when needed.
Testing and Maintaining Password Policies
Whenever you change password policy, you should test it. This includes both technical testing and practical testing with real users or test accounts.
From a technical perspective, you should:
Try to change a password for a test user using passwd and verify that the complexity rules behave as expected.
Check that lockout thresholds are enforced and that accounts unlock after the configured time or by administrative action.
Use chage -l to confirm aging values for test accounts after setting defaults in /etc/login.defs and creating new users.
From a practical perspective, you need to ensure that your policy is understandable and reasonable. If users constantly encounter errors when setting or changing passwords, they may resort to unsafe workarounds.
Always document your password policy and communicate it to users before enforcing stricter rules. Unexpected policy changes can lock users out and generate support issues, especially if aging or lockout thresholds are tightened without notice.
Over time, password policy best practices change. Modern security guidance sometimes recommends longer, easier to remember passphrases rather than very complex short passwords. In some environments, administrators combine moderate password policies with additional protections such as multi factor authentication. On a Linux server, password policies are still a central tool, but they work best when combined with other security measures you will learn about in later chapters.
In daily administration, you will often revisit these settings as security requirements evolve. Understanding where aging, complexity, lockout, and history rules live in your Linux system lets you adjust them safely and deliberately instead of relying on distribution defaults.