Like the name implies this series are short entries intended to quickly show and explain configuring a security component which will include resources the viewer can use to research the topic in more depth.

These shorts can be implemented as a single stand-alone security change or combined together with other security shorts to harden your servers, nodes and oracles. Implementing all of them will provide a very secure configuration. We hope they are not only educational but you enjoy the quick and to the point format.

Restricting Password Reuse

Here’s how to restrict users from reusing passwords. This is handled by Linux Pluggable Authentication Modules, or PAM.

The files we will be working with today are /etc/pam.d/system-auth and /etc/security/opasswd.

The requirements for preventing password reuse are the system module must be required in the system-auth pam file; /etc/security/opasswd needs to: exist; have correct permissions/ownership; have correct SELinux context.

First we are going to connect to the system’s user-account.

Next we’re going to switch to the root account via “sudo su“.

Next we are going to confirm that /etc/security/opasswd exist; have correct permissions and ownership and SELinux context type of shadow_t.

Now we are going to edit the system-auth file. And below we are going to add a line of password required remember=5 and use_authtok. This causes the history module to remember the last 5 passwords and prevent them from being reused.

Password Expiration

Now let’s walk through how to configure password expiration requirements for both new and existing accounts. This is part of the login definitions of your Linux system.

The file that contains the site specific login definitions is /etc/login.defs, this file controls a great many settings of your system, but today we will focus on the PASS_MAX_DAYS and PASS_WARN_AGE parameters. And we’re going to use the `useradd` and `chage` utilities to examine some accounts, create accounts and examine the system.

Let’s take a look by first connecting to the system’s user-account. Next we’re going to switch to the root user via “sudo su“.

Now before making a change I will add a user account named service-account, using the useradd utility. Then we’re going to go into the systems login.defs file and set the PASS_MAX_DAYS from 99 thousand to 180 days.

Now after changing the defaults let’s useradd an account named access-account and using the `chage` utility with a -l, for list, to show the account aging information.

Here we can see that the access-account created with 180 day Maximum password expiration, and looking at the service account it still has 99 thousand day expiration.

Using the `chage` -[capital m]M flag to set MAX password expiration, we can change the service account to 180 days and now it matches the access account.

I’ve never liked 7 day notifications. Let’s change it by using `chage` with the -W flag for WARN_DAYS flag to 21 days for the access and service accounts, Then lets go ahead and set this system-wide by editing the login.defs and setting the PASS_WARN_AGE to 21.

Password Complexity

You’ve made it this far — congrats! Now it’s time to learn how to configure your password complexity requirements. This is handled by Linux Pluggable Authentication Modules, or PAM.

There are two files that control password complexity (aka quality): /etc/pam.d/system-auth & /etc/security/pwquality.conf. The requirements are system module must be called for passwords in the system-auth pam file. All configuration changes should be placed in the pwquality.conf file.

Let’s start off by connecting to the system’s user account and then switch to the root user with “sudo su”.

Now we will verify the system-auth PAM file calls the module. Here we can see the line with the module. Since that is proper we can move on to configuration.

First by setting difok = 4 I can ensure each change the new password has at least 4 characters different from the prior password.

Next I can increase the minimum password length to 12 by setting the minlen parameter.

To require at least one digit set dcredit to negative 1

To require at least one uppercase letter set ucredit to negative 1, if we wanted 2 uppercase characters we could set it to negative 2.

To require at at least one lowercase letter set lcredit to negative 1

To requires at least one other/special character set ocredit to negative 1

If we instead wanted the password to have at least three of the 4 classes we would set minclass to 3. However defining each credit like I did above overrides minclass, requiring all 4 classes.

To set a limit of 3 repeating identical characters, we can set the maxrepeat parameter.

A Cardano Stake Pool with best in class security.