Americas

  • United States
sandra_henrystocker
Unix Dweeb

How to ensure users periodically update their passwords on Linux

How-To
Mar 14, 20243 mins
Linux

Requiring password changes is a common security practice, and Linux systems admins can use the chage command to view and change password expiration information.

woman logging in to laptop with password
Credit: Shutterstock

Ensuring that users change their passwords from time to time is a practice that many system admins follow as part of their security plans. It’s an important step in cyber-defense because it lessens the likelihood that passwords will be compromised. At the same time, requiring overly frequent changes might have unintended side effects; users can be tempted to write down their passwords, or make them so much easier to remember that it becomes easier for someone else to guess what they might be.

Fortunately, Linux systems have a way to enforce some timing rules on how frequently passwords must be changed. The /etc/login.defs file allows you to set the parameters that control how long a password can be active before it expires (PASS_MAX_DAYS). It also allows you to set the minimum number of days that a password must remain active (PASS_MIN_DAYS). This second of these parameters ensures that a user can’t change his/her password and then reset it to the former password – basically amounting to no change.

Users can also be granted a warning period during which they are alerted to the fact that their passwords will soon expire (PASS_WARN_DAYS) and giving them time to reflect on passwords that would both be hard to guess and relatively easy to remember.

If you simply go with the defaults, the settings will undoubtedly result in NO password expirations. The default for the PASS_MAX_DAYS setting is 99999 and that is roughly 273 years. With a value like that, no one is going to see their password expiring.

The values for the last password change, the minimum password age, and the maximum password age are stored in the /etc/shadow file. You might see strings of values that look like “19790:0:99999” for these values. In this example, the first value (19790) represents the date of the last change (days since Jan 1, 1970). The 0 is the minimum number of days before a password can be changed again. The third is, of course, the 273 year default for password expiration.

To change the default settings in the /etc/login.defs file, you could, for example, change the values that look like what you see on the left to something like what you see on the right to alter them to enforce password aging limitations.

PASS_MAX_DAYS   99999        PASS_MAX_DAYS   99
PASS_MIN_DAYS   0            PASS_MIN_DAYS   9
PASS_WARN_AGE   7            PASS_WARN_AGE   9

There is, however, an issue with making these changes. They will not affect existing users. Their settings in the /etc/shadow file will not be altered. In order to enforce the password limitations for current accounts, you will have to use the chage command, which lets you both view and change password expiration information. Here’s an example:

# chage lola
Changing the aging information for lola
Enter the new value, or press ENTER for the default

        Minimum Password Age [0]: 9
        Maximum Password Age [99999]: 99
        Last Password Change (YYYY-MM-DD) [2023-03-08]:
        Password Expiration Warning [7]: 9
        Password Inactive [-1]:
        Account Expiration Date (YYYY-MM-DD) [-1]:

Note that responses were only provided for the first, second and fourth prompts.

Once the settings have been changed with the chage command, they will go into effect.

sandra_henrystocker
Unix Dweeb

Sandra Henry-Stocker has been administering Unix systems for more than 30 years. She describes herself as "USL" (Unix as a second language) but remembers enough English to write books and buy groceries. She lives in the mountains in Virginia where, when not working with or writing about Unix, she's chasing the bears away from her bird feeders.

The opinions expressed in this blog are those of Sandra Henry-Stocker and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.