Creating a password policy on Linux

Hello again! Classes will begin tomorrow in the new group of the Linux Administrator course , and in this regard we are publishing a useful article on the topic.



In the last tutorial, we talked about how to use pam_cracklibit to complicate passwords on Red Hat 6 or CentOS systems . In Red Hat 7 pam_pwqualityreplaced cracklibas pamthe default module for password verification. The module is pam_pwqualityalso supported on Ubuntu and CentOS, as well as on many other operating systems. This module makes it easy to create password policies to make sure that users accept your password complexity standards.

For a long time, the usual approach to passwords was to force the user to use upper and lower case characters, numbers, or other characters in them. These basic password complexity rules have been actively promoted in the last ten years. There has been a lot of discussion about whether this is good practice or not. The main argument against setting such difficult conditions was that users write passwords on paper and store it insecurely.

Another policy that has recently been called into question forces users to change their passwords every x days. Several studies have been carried out which have shown that this is also detrimental to safety.

A lot of articles have been written on the topic of these discussions that justify this or that point of view. But this is not what we will discuss in this article. This article will tell you how to correctly set the password complexity, and not manage the security policy.

Password Policy Settings

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

• difok - The number of characters in your new password that should NOT be present in your old password. (Default is 5)
• minlen - The minimum password length. (Default is 9)
• ucredit - The maximum number of credits for using uppercase characters (if parameter> 0), or the minimum required number of uppercase characters (if parameter <0). The default is 1.
• lcredit - The maximum number of credits for using lowercase characters (if parameter> 0), or the minimum required number of lowercase characters (if parameter <0). The default is 1.
• dcredit - The maximum number of credits for using digits (if parameter> 0), or the minimum required number of digits (if parameter <0). The default is 1.
• ocredit - The maximum number of credits for using other symbols (if parameter> 0), or the minimum required number of other symbols (if parameter <0). The default is 1.
• minclass - Sets the number of required classes. Classes include the above parameters (upper case, lower case, numbers, other characters). The default is 0.
• maxrepeat - The maximum number of times a character is repeated in a password. The default is 0.
• maxclassrepeat - The maximum number of consecutive characters in a single class. The default is 0.
• gecoscheck - Checks if the password contains any words from the user's GECOS lines. (User information, i.e. real name, location, etc.) Default 0 (off).
• dictpath - Let to cracklib dictionaries.
• badwords - Space -separated words that are prohibited in passwords (company name, word "password", etc.).

If the concept of loans sounds strange, it's okay, that's fine. We will talk about this in more detail in the following sections.

Configuring a password policy

Before you start editing configuration files, it is good practice to pre-write a basic password policy. For example, we will use the following complexity rules:

• Password must have a minimum length of 15 characters.
• In the password, the same character should not be repeated more than two times.
• In a password, character classes can be repeated up to four times.
• The password must contain characters from each class.
• The new password must have 5 new characters compared to the old one.
• Enable GECOS Validation.
• Deny the words "password, pass, word, putorius"

Now, as soon as we set out the policy, we can edit the file /etc/security/pwquality.confto strengthen the password complexity requirements. Below is an example commentary file 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 is minclassredundant, since we already use at least two characters from the class using fields [u,l,d,o]credit. Our list of words that cannot be used is also redundant, since we have forbidden the repetition of any class 4 times (all words in our list are written in lower case). I have included these options only to demonstrate how to use them to configure a password policy.
Once you have created the policy, you can force users to change their passwords the next time they log on to the system .

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

What are loans?

I call them loans, because it accurately conveys their purpose. If the parameter value is greater than 0, you add the number of "credits per characters" equal to "x" to the length of the password. For example, if you set all the parameters (u,l,d,o)creditto 1, and the required password length was 6, then you will need 6 characters to satisfy the length requirement, because each upper case, lower case, digit or other character will give you one credit.

If you installdcreditIn 2, you can theoretically use a password with a length of 9 characters and get 2 credits for characters for numbers, and then the password can already be 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 was less than 13 characters long. The next time I changed the letter “I” to the number “1” and received two credits for the numbers, which equated the password to 13.

Testing the password

The package libpwqualityprovides the functionality described in the article. It also comes with a program pwscorethat is designed to check the password for complexity. We used it above to check loans.

The utility pwscorereads from stdin . Just run the utility and write your password, it will give an error or a value from 0 to 100.

The quality indicator of the password is related to the parameterminlenin the configuration file. In general, an indicator less than 50 is considered as a “normal password”, and above as a “strong password”. Any password that passes quality checks (especially forced verification cracklib) must withstand dictionary attacks, and a password with a score above 50 with a default setting minlenof even brute forceattacks.

Conclusion

Customization pwqualityis quick and easy compared to the inconvenience of using cracklibdirect file editing pam. In this guide, we've covered everything you need to set up password policies on Red Hat 7, CentOS 7, and even Ubuntu systems. We also talked about the concept of loans, which are rarely written in detail, so this topic often remained incomprehensible to those who had 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