How to set a password management policy for users, and manually lock and unlock user accounts in CentOS/RHEL

shadow passwords and password policy

At one time, encrypted passwords were stored in the world-readable /etc/passwd file. This was thought to be reasonably secure until dictionary attacks on encrypted passwords became common. At that point, the encrypted passwords were moved to a separate /etc/shadow file which is readable only by root. This new file also allowed password aging and expiration features to be implemented.

Like /etc/passwd, each user has a line in the /etc/shadow file. A sample line from /etc/ shadow with its nine colon-separated fields is shown below.

1. Username of the account this password belongs to.
2. The encrypted password of the user. The format of encrypted passwords is discussed later in this section.
3. The day on which the password was last changed. This is set in days since 1970-01-01 and is calculated in the UTC time zone.
4. The minimum number of days that have to elapse since the last password change before the user can change it again.
5. The maximum number of days that can pass without a password change before the password expires. An empty field means it does not expire based on time since the last change.
6. Warning period. The user will be warned about an expiring password when they login for this number of days before the deadline.
7. Inactivity period. Once the password has expired, it will still be accepted for login for this many days. After this period has elapsed, the account will be locked.
8. The day on which the password expires. This is set in days since 1970-01-01 and is calculated in the UTC time zone. An empty field means it does not expire on a particular date.
9. The last field is usually empty and is reserved for future use.

Format of an Encrypted Password

The encrypted password field stores three pieces of information: the hashing algorithm used, the salt, and the encrypted hash. Each piece of information is delimited by the $ sign.

1. The hashing algorithm used for this password. The number 6 indicates it is a SHA-512 hash, which is the default in Red Hat Enterprise Linux 8. A 1 would indicate MD5, a 5 SHA-256.
2. The salt used to encrypt the password. This is originally chosen at random.
3. The encrypted hash of the user’s password. The salt and the unencrypted password are combined and encrypted to generate the encrypted hash of the password.

The use of salt prevents two users with the same password from having identical entries in the / etc/shadow file. For example, even if user01 and user02 both use mypass as their passwords, their encrypted passwords in /etc/shadow will be different if their salts are different.

Password Verification

When a user tries to log in, the system looks up the entry for the user in /etc/shadow, combines the salt for the user with the unencrypted password that was typed in, and encrypts them using the hashing algorithm specified. If the result matches the encrypted hash, the user typed in the right password. If the result does not match the encrypted hash, the user typed in the wrong password and the login attempt fails. This method allows the system to determine if the user typed in the correct password without storing that password in a form usable for logging in.

CONFIGURING PASSWORD AGING

The following diagram relates the relevant password aging parameters, which can be adjusted using the chage command to implement a password aging policy.

[user01@host ~]$ sudo chage -m 0 -M 90 -W 7 -I 14 user03

- The preceding chage command uses the -m, -M, -W, and -I options to set the minimum age, maximum age, warning period, and inactivity period of the user’s password, respectively. - The ‘chage -d 0 user03’ command forces the user03 user to update its password on the next login. - The ‘chage -l user03’ command displays the password aging details of user03. - The ‘chage -E 2019-08-05 user03’ command causes the user03 user’s account to expire on 2019-08-05 (in YYYY-MM-DD format).

[user01@host ~]$ date -d "+45 days" -u
Thu May 23 17:01:20 UTC 2019

Edit the password aging configuration items in the /etc/login.defs file to set the default password aging policies. The PASS_MAX_DAYS sets the default maximum age of the password. The PASS_MIN_DAYS sets the default minimum age of the password. The PASS_WARN_AGE sets the default warning period of the password. Any change in the default password aging policies will be effective for new users only. The existing users will continue to use the old password aging settings rather than the new ones.

RESTRICTING ACCESS

You can use the chage command to set account expiration dates. When that date is reached, the user cannot log in to the system interactively. The usermod command can lock an account with the -L option.

[user01@host ~]$ sudo usermod -L user03
[user01@host ~]$ su - user03
Password: mypass
su: Authentication failure

If a user leaves the company, the administrator may lock and expire an account with a single usermod command. The date must be given as the number of days since 1970-01-01, or in the YYYY-MM-DD format.

[user01@host ~]$ sudo usermod -L -e 2019-10-05 user03

The preceding usermod command uses the -e option to set the account expiry date for the given user account. The -L option locks the user’s password. Locking the account prevents the user from authenticating with a password to the system. It is the recommended method of preventing access to an account by an employee who has left the company. If the employee returns, the account can later be unlocked with usermod -U. If the account was also expired, be sure to also change the expiration date.

The nologin Shell

The nologin shell acts as a replacement shell for the user accounts not intended to interactively log into the system. It is wise from a security standpoint to disable the user account from logging into the system when the user account serves a responsibility that does not require the user to log into the system. For example, a mail server may require an account to store mail and a password for the user to authenticate with a mail client used to retrieve mail. That user does not need to log directly into the system.

A common solution to this situation is to set the user’s login shell to /sbin/nologin. If the user attempts to log in to the system directly, the nologin shell closes the connection.

[user01@host ~]$ usermod -s /sbin/nologin user03
[user01@host ~]$ su - user03
Last login: Wed Feb  6 17:03:06 IST 2019 on pts/0
This account is currently not available