Red Hat System Administration I
Objectives
After completing this section, you should be able to set a password management policy for users, and manually lock and unlock user accounts.
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.
user03:
$6$CSsX...output omitted...:
17933:
0:
99999:
7:
2:
18113:
| Username of the account this password belongs to. |
| The encrypted password of the user. The format of encrypted passwords is discussed later in this section. |
| 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. |
| The minimum number of days that have to elapse since the last password change before the user can change it again. |
| 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. |
| Warning period. The user will be warned about an expiring password when they login for this number of days before the deadline. |
| 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. |
| The day on which the account 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. |
| 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.
$
|
The hashing algorithm used for this password.
The number |
| The salt used to encrypt the password. This is originally chosen at random. |
| 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 primary reason to combine a salt with the password is to defend against attacks using pre-computed lists of password hashes.
Adding salts changes the resulting hashes, making the pre-computed list useless.
If an attacker is able to obtain a copy of an /etc/shadow file that is using salts, they will need to perform brute-force password guessing, requiring more time and effort.
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 -m0-M90-W7-I14user03
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).
Note
The date command can be used to calculate a date in the future.
The -u option reports the time in UTC.
[user01@host ~]$date -d "+Thu May 23 17:01:20 UTC 201945days" -u
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 -Luser03[user01@host ~]$su -user03Password:su: Authentication failureredhat
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 -e2019-10-05user03
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 an account from logging into the system, when the account does not require it. 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/nologinuser03[user01@host ~]$su -Last login: Wed Feb 6 17:03:06 IST 2019 on pts/0 This account is currently not available.user03
Important
The nologin shell prevents interactive use of the system, but does not prevent all access. Users might be able to authenticate and upload or retrieve files through applications such as web applications, file transfer programs, or mail readers if they use the user's password for authentication.
References
chage(1), usermod(8), shadow(5), crypt(3) man pages
