Creating a password policy in Linux

Hello again! Classes start tomorrow in the new group of the course "Linux Administrator", in connection with this we publish a useful article on the topic.

Creating a password policy in Linux

In the last tutorial we showed you how to use pam_cracklibto complicate passwords on systems Red Hat 6 or CentOS. In Red Hat 7 pam_pwquality replaced cracklib as pam default module for checking passwords. Module pam_pwquality also supported on Ubuntu and CentOS, as well as many other operating systems. This module makes it easy to create password policies to make sure users accept your password complexity standards.

For a long time, the common approach to passwords was to force the user to use uppercase, lowercase, numbers, or other characters in them. These basic password complexity rules have been heavily promoted over the past ten years. There has been a lot of discussion about whether this is a good practice or not. The main argument against setting such complex conditions was that users write down passwords on pieces of paper and store them insecurely.

Another policy that has recently been called into question is forcing users to change their passwords every x days. There have been some studies that have shown that this is also detrimental to safety.

On the topic of these discussions, many articles have been written that substantiate one or another point of view. But this is not what we will discuss in this article. This article will talk about how to correctly set the complexity of the password, and not manage the security policy.

Password policy settings

Below you will see the password policy settings and a brief description of each. Many of them are similar to the parameters in the module cracklib. This approach makes it easier 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 5)
  • minlen – Minimum password length. (Default 9)
  • ucredit – The maximum number of credits for using upper case characters (if parameter > 0), or the minimum required number of upper case characters (if parameter < 0). The default is 1.
  • credit β€” The maximum number of credits for using lowercase characters (if parameter > 0), or the minimum number of lowercase characters required (if parameter < 0). The default is 1.
  • dcredit β€” The maximum number of credits for using digits (if parameter > 0), or the minimum number of digits required (if parameter < 0). The default is 1.
  • credit β€” 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.
  • min class – Sets the number of required classes. The classes include the above parameters (upper case, lower case characters, numbers, other characters). The default is 0.
  • max repeat – The maximum number of repetitions of a character in a password. The default is 0.
  • maxclassrepeat β€” The maximum number of consecutive characters in one class. The 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 0 (disabled).
  • dictpath – Let to cracklib dictionaries.
  • badwords – Space-separated words that are not allowed in passwords (Company name, the word "password", etc.).

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

Password policy configuration

Before you start editing configuration files, it's good practice to write down a basic password policy in advance. For example, we will use the following difficulty 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 can be repeated up to four times in a password.
  • The password must contain characters from each class.
  • The new password must have 5 new characters compared to the old one.
  • Enable GECOS verification.
  • Prohibit the words "password, pass, word, putorius"

Now, once we have laid out the policy, we can edit the file /etc/security/pwquality.confto enforce 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 can see, some parameters in our file are redundant. For example, the parameter minclass redundant since we are already using at least two characters from the class using fields [u,l,d,o]credit. Our list of words that can't be used is also redundant because we've banned any class from being repeated 4 times (all the words in our list are in lowercase). I included these options only to demonstrate how to use them to set up a password policy.
Once you've created your policy, you can force users to change their passwords the next time they log in. 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 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 credits?

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

If you install dcredit in 2, you could theoretically use a password of 9 characters and get 2 character credits for numbers, and then the password could already be 10 characters long.

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 made the password equal to 13.

Password testing

Plastic bag 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 credits.
Utility pwscore reads from stdin. Just run the utility and write your password, it will return an error or a value from 0 to 100.

The password quality score correlates with the parameter minlen in the configuration file. In general, a score below 50 is considered a "normal password" and a score above XNUMX is considered a "strong password". Any password that passes quality checks (especially forced cracklib) must withstand dictionary attacks, and a password above 50 with the setting minlen even by default brute force attacks.

Conclusion

Setting pwquality – it is easy and simple compared to the inconvenience of using cracklib with direct 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 is rarely covered in detail, so this topic often remained incomprehensible to those who had not previously encountered it.

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

Add a comment