IDG Contributor Network: The complexity of password complexity
Credit to Author: Sandra Henry-Stocker| Date: Thu, 25 May 2017 05:47:00 -0700
Deploying password quality checking on your Debian-base Linux servers can help to ensure that your users assign reasonable passwords on their accounts, but the settings themselves can be a bit misleading. For example, setting a minimum password length of 12 characters does not mean that your users’ passwords will all have twelve or more characters. Let’s stroll down Complexity Boulevard and see how the settings work and examine some settings worth considering.
First, if you haven’t done this already, install the password quality checking library with this command:
The files that contain most of the settings we’re going to look at will be:
Here’s how it works. You can set a minimum password length, but it doesn’t work exactly like you might think. People can set themselves up with shorter passwords if they incorporate some additional complexity and get credit for doing so.
Complexity settings allow you to do quite a number of things in addition to requiring a minimum password length. You can require:
The settings include:
Implementing these settings in your common-password file might look like this:
The idea of “credits” is very interesting. Basically, you’re getting credit for complexity. A shorter password might be acceptable if it’s more complex in other ways — like the mix of characters – than length.
As an example, a password like “hijlmqrazp” might pass a minlen=10 test. If dcredit is set to 2, on the other hand, the password “hijlmq99” would also pass. Why? Because we’d get 2 credits for the digits. So, 8 characters plus 2 credits is valued as highly as 10 characters. If dcredit was set to 1, you would need an additional character. However, we could get credits for uppercase, lowercase, and non-alphanumeric characters (like punctuation characters).
Note, however, that you can only get credit for so many of the different characters. Maybe you will get credit for only one digit or two uppercase characters. Maybe you don’t get any credit for lowercase characters. It all depends on your settings.
One other setting which comes into play is the minclass setting. This setting determines how many different classes of characters – must be used for a password to be acceptable. If minclass is set to 2, a password containing all lowercase, all uppercase, all digits, or all other characters wouldn’t work. If set to 2, minclass would require you to use characters from two classes – like uppercase and lowercase, or lowercase and digits.
With minclass set to 4, passwords would have to include all four types of characters – like “howzit2B?” and, if we get credit for uppercase, digits, or other characters, we’d be OK even with the minlen set to 12.
You can also put a cap on the number of characters of any particular class. Set the maxclassrepeat setting to 4 and passwords cannot contain more than 4 lowercase, uppercase, digits, or other characters in succession.
Setting one of the lcredit, ucredit, dcredit, or ocredit settings to a negative number means that you MUST have some of that type of character. Setting dcredit to -1, for example, would mean that you have to include at least one digit for a password to be accepted.
PAM’s password quality checking also includes a number of other checks that help ensure that passwords are fairly secure. It checks to see if a password is a palindrome (e.g., “racecar”), whether a new password is the same as the old password but with a change of case only, if the old and new passwords are too similar or rotations of each other, and whether a password contains the user’s name. It’s getting to the point that it might actually be difficult to assign oneself a really bad password.
This article is published as part of the IDG Contributor Network. Want to Join?