Creating a password policy in Linux.

Hello again! Classes in the new group of the course begin tomorrow. Linux Administrator, so we are publishing a helpful article on the topic.

Creating a password policy in Linux.

In the previous tutorial, we discussed how to use pam_cracklib, to complicate passwords in systems. Red Hat 6 or CentOS. In Red Hat 7, pam_pwquality replaced cracklib as pam as the default module for password checks. The module pam_pwquality is also supported in Ubuntu and CentOS, as well as in many other OSes. This module simplifies the creation of password policies to ensure that users meet your password complexity standards.

For a long time, the common approach to passwords was to force users to include uppercase and lowercase letters, numbers, or other characters. These basic password complexity rules have been actively promoted over the past ten years. There have been many discussions about whether or not this is good practice. The main argument against imposing such complex conditions was that users write down passwords on paper and store them insecurely.

Another policy that has recently come under scrutiny requires users to change their passwords every x days. Some studies have shown that this also harms security.

Many articles have been written on these discussions, justifying one viewpoint or another. However, this is not what we will discuss in this article. This article will focus on how to properly set password complexity, not on managing security policy.

Password Policy Parameters

Below you will see the password policy parameters and a brief description of each. Many of them are similar to the parameters in the module. cracklib. This approach simplifies the porting of your policies from the old system.

  • difok – The number of characters in your new password that MUST NOT be present in your old password. (Default is 5)
  • minlen – Minimum password length. (Default is 9)
  • ucredit – Maximum number of credits for using uppercase letters (if the parameter > 0), or the minimum required number of uppercase letters (if the parameter < 0). Default is 1.
  • lcredit — Maximum number of credits for using lowercase letters (if the parameter > 0), or the minimum required number of lowercase letters (if the parameter < 0). Default is 1.
  • dcredit — Maximum number of credits for using digits (if the parameter > 0), or the minimum required number of digits (if the parameter < 0). Default is 1.
  • ocredit — Maximum number of credits for using other characters (if the parameter > 0), or the minimum required number of other characters (if the parameter < 0). Default is 1.
  • minclass – Sets the required number of classes. Classes include the above parameters (uppercase letters, lowercase letters, digits, other characters). Default is 0.
  • maxrepeat – Maximum number of repetitions of a character in the password. Default is 0.
  • maxclassrepeat — Maximum number of consecutive characters in one class. Default is 0.
  • gecoscheck – Checks if the password contains any words from the user's GECOS strings. (User information, i.e., real name, location, etc.) Default is 0 (disabled).
  • dictpath – Path to cracklib dictionaries.
  • badwords – Space-separated words that are prohibited in passwords (Company name, the word “password,” etc.).

If the concept of credits sounds strange, don't worry, it's perfectly fine. We will discuss this in more detail in the following sections.

Password Policy Configuration

Before you start editing configuration files, it's a good practice to write down a basic password policy in advance. For example, we will use the following complexity rules:

  • The password must have a minimum length of 15 characters.
  • The same character must not be repeated more than twice in the password.
  • Character classes in the password may repeat up to four times.
  • The password must contain characters from each class.
  • The new password must have 5 new characters compared to the old.
  • Enable GECOS checking.
  • Disallow the words “password, pass, word, putorius”.

Now that we have outlined the policy, we can edit the file /etc/security/pwquality.conf, to strengthen the password complexity requirements. Below is an example file with comments for better understanding.

# Make sure 5 characters in new password are new compared to old password
difok = 5
# Set the minimum length acceptable for new passwords
minlen = 15
# Require at least 2 digits
dcredit = -2
# Require at least 2 upper case letters
ucredit = -2
# Require at least 2 lower case letters
lcredit = -2
# Require at least 2 special characters (non-alphanumeric)
ocredit = -2
# Require a character from every class (upper, lower, digit, other)
minclass = 4
# Only allow each character to be repeated twice, avoid things like LLL
maxrepeat = 2
# Only allow a class to be repeated 4 times
maxclassrepeat = 4
# Check user information (Real name, etc) to ensure it is not used in password
gecoscheck = 1
# Leave default dictionary path
dictpath =
# Forbid the following words in passwords
badwords = password pass word putorius

As you may have noticed, some parameters in our file are redundant. For example, the parameter minclass is redundant because we're already using at least two characters from the class by utilizing fields [u,l,d,o]credit. Our list of prohibited words is also redundant since we've banned the repetition of any class 4 times (all words on our list are written in lowercase). I included these parameters only to demonstrate how to use them to configure password policy.
Once you have created your policy, you can enforce users to change their passwords upon their next login to the system.

Another strange thing you may have noticed is that the fields [u,l,d,o]credit contain a negative number. This is because numbers greater than or equal to 0 will grant credits for using a symbol in your password. If a field contains a negative number, it means a certain amount is required.

What are credits (credit)?

I refer to them as credits because it most accurately conveys their purpose. If the parameter value is greater than 0, you add the number of 'character credits' equal to 'x' to the password length. For example, if all parameters (u,l,d,o)credit are set to 1, and the required password length was 6, then you would need 6 characters to meet the length requirement, because each uppercase, lowercase, digit, or other symbol gives you one credit.

If you set dcredit to 2, you could theoretically use a password of length 9 and receive 2 character credits for digits, making the password length 10.

Look at this example. I set the password length to 13, set dcredit to 2, and everything else to 0.

$ pwscore
 Thisistwelve
 Password quality check failed:
  The password is shorter than 13 characters

$ pwscore
 Th1sistwelve
 18

My first check failed because the password length was less than 13 characters. The next time, I changed the letter “I” to the number “1” and got two credits for digits, bringing the password to 13.

Password Testing

The package libpwquality provides the functionality described in the article. It also comes with a program pwscore, which is designed to check the password for complexity. We used it above to check the credits.
Utility pwscore reads from stdin. Just run the utility and enter your password; it will return either an error or a value from 0 to 100.

The password quality score corresponds to the parameter minlen in the configuration file. In general, a score below 50 is considered a 'normal password', while above that is seen as a 'strong password'. Any password that passes quality checks (especially the enforced check cracklib) must withstand dictionary attacks, and a password with a score above 50 with the setting minlen by default even brute force attacks.

Conclusion

Settings pwquality – it’s easy and straightforward compared to the inconveniences of using cracklib direct file editing pam. In this guide, we covered everything you will need when setting up password policies in Red Hat 7, CentOS 7, and even Ubuntu systems. We also discussed the concept of credits, which is rarely written about in detail, making this topic often unclear to those who have not encountered it before.

Sources:

pwquality man page
pam_pwquality man page
pwscore man page

Useful links:

Choosing Secure Passwords – Bruce Schneier
Lorrie Faith Cranor discusses her password studies at CMU
The Infamous xkcd cartoon on Entropy

Source: habr.com

Buy reliable website hosting with DDoS protection, VPS VDS servers 🔥 Buy reliable website hosting with DDoS protection, VPS VDS servers | ProHoster