|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Skepticism and critical thinking is not panacea, but can help to understand the world better
This module can be plugged into the password stack of a given application to provide some plug-in strength-checking for passwords.
The action of this module is to prompt the user for a password and check its strength against a system dictionary and a set of rules for identifying poor choices.
The first action is to prompt for a single password, check its strength and then, if it is considered strong, prompt for the password a second time (to verify that it was typed correctly on the first occasion). All being well, the password is passed on to subsequent modules to be installed as the new authentication token.
The strength checks works in the following manner: at first the Cracklib routine is called to check if the password is part of a dictionary; if this is not the case an additional set of strength checks is done. These checks are:
To avoid the lockup associated with trying to change a long and complicated password, difignore is available. This argument can be used to specify the minimum length a new password needs to be before the difok value is ignored. The default value for difignore is 23.
(N < 0) This is the minimum number of digits that must be met for a new password.
(N > 0) This is the minimum number of upper case letters that must be met for a new password.
(N < 0) This is the minimum number of lower case letters that must be met for a new password.
(N < 0) This is the minimum number of other characters that must be met for a new password.
Only he password service is supported.
For an example of the use of this module, we show how it may be stacked with the password component of pam_unix(8)
# # These lines stack two password type modules. In this example the # user is given 3 opportunities to enter a strong password. The # "use_authtok" argument ensures that the pam_unix module does not # prompt for a password, but instead uses the one provided by # pam_cracklib. # passwd password required pam_cracklib.so retry=3 passwd password required pam_unix.so use_authtok
#%PAM-1.0 # # These lines allow a md5 systems to support passwords of at least 14 # bytes with extra credit of 2 for digits and 2 for others the new # password must have at least three bytes that are not present in the # old password # password required pam_cracklib.so \ difok=3 minlen=15 dcredit= 2 ocredit=2 password required pam_unix.so use_authtok nullok md5
#%PAM-1.0 # # These lines require the user to select a password with a minimum # length of 8 and with at least 1 digit number, 1 upper case letter, # and 1 other character # password required pam_cracklib.so \ dcredit=-1 ucredit=-1 ocredit=-1 lcredit=0 minlen=8 password required pam_unix.so use_authtok nullok md5
Linux Password Security with pam_cracklib
The pam_cracklib module is enabled via the system's standard PAM configuration interface. On Debian systems, this is the /etc/pam.d/common-password file (but it's /etc/pam.d/system-auth on RedHat-derived systems--can't we all just get along?). The typical configuration looks something like this:
password required pam_cracklib.so retry=3 minlen=6 difok=3
password required pam_unix.so md5 use_authtok
The first line enables the pam_cracklib module and sets several module parameters. "retry=3" means that users get three chances to pick a good password before the passwd program aborts. Users can always re-run the passwd program and start over again, however. "minlen=6" sets the minimum number of characters in the password. Actually, since Linux systems generally use MD5 password hashes, which are not limited to 8 character passwords like the old DES56 hashes, you probably want to think about increasing the "minlen" parameter to something a bit longer. We'll come back to this notion a bit later in the article. "difok=3" sets the minimum number of characters that must be different from the previous password. If you increase "minlen", you may also want to increase this value as well.
The second line invokes the standard pam_unix module. The "md5" argument here is what enables standard Linux MD5 password hashes, though you have the option of using old-style DES56 hashes for backwards compatibility with legacy Unix systems. "use_authtok" tells pam_unix to not bother doing any of its own internal password checks, which duplicate many of the checks in pam_cracklib, but instead accept the password that the user inputs after it's been thoroughly checked by pam_cracklib.
By default, pam_cracklib performs a number of basic checks on the new password:
- Is the new password just the old password with the letters reversed ("password" vs. "drowssap") or rotated ("password" vs. "asswordp")?
- Does the new password only differ from the old one due to change of case ("password" vs. "Password")?
- Are at least some minimum number of characters in the new password not present in the old password? This is where the "difok" parameter comes into play.
These are the same checks you get in the pam_unix module if you turn on the "obscure" flag, but since we're already using pam_cracklib we don't need to do this.
Length and Strength
While the "minlen" parameter controls the minimum password length, things are not as simple as they might appear. This is because pam_cracklib combines the notion of password length with password "strength" (the use of mixed-case and non-letter characters).
"minlen" is actually the minimum required length for a password consisting of all lower-case letters. But users get "length credits" for using upper- and lower-case letters, numbers, and non-alphanumeric characters. The default is normally that you can only get a maximum of "1 credit" for each type of character. So if the administrator sets "minlen=12", a user could still have an 8 character password if they used all four types of characters. Actually, since using a lower-case letter gets you a credit, the real minimum length for an all lower-case password is minlen-1.
The maximum credit for any particular class of characters is actually customizable. The four parameters "lcredit", "ucredit", "dcredit", and "ocredit" are used to set the maximum credit for lower-case, upper-case, numeric (digit), and non-alphanumeric (other) characters, respectively. For example, you could add the following parameters on the pam_cracklib line in the /etc/pam.d/common-password file:
lcredit=0 ucredit=1 dcredit=1 ocredit=2
In other words, lower-case characters aren't special at all, so you get no credit there. On the other hand we give extra credit if the user puts two or more non-alphanumeric characters in their password. One point is still the max credit for upper-case characters and numbers. Note that no matter what you set "minlen" to and no matter how many "credits" you give to your users, pam_cracklib will never let users pick passwords with less than six characters--this is a hard-coded internal minimum.
Play around with these values and find something that makes sense for your site, but as a starting point I might recommend "minlen=12 difok=4" for machines using MD5 password hashes. This means that the smallest password a user could have is 8 characters, and that's only if they use all four character sets.
pam_cracklib also checks the user's password against it's own internal dictionaries of easily guessed passwords. On Debian systems, pam_cracklib's dictionaries live in /var/cache/cracklib and are rebuilt nightly by the
/usr/sbin/update-cracklib script. Other Linux distros may have other mechanisms for updating the dictionaries (as far as I can tell, RedHat doesn't provide any tools for doing this).
The update-cracklib script searches a number of directories for input files, including /usr/local/dict and /usr/local/share/dict. So adding your own words is as easy as putting them in a file in one of these directories and running update-cracklib or waiting for cron to do it for you. Note that if you want to add other directories to update-cracklib's search path, you can do this by modifying the /etc/cracklib/cracklib.conf file (at least on Debian systems).
pam_cracklib is capable of consulting a user's password "history" and not allowing them to re-use old passwords. However, the functionality for actually storing the user's old passwords is enabled via the pam_unix module.
The first step is to make sure to create an empty /etc/security/opasswd file for storing old user passwords. If you forget to do this before enabling the history feature in the PAM configuration file, then all user password updates will fail because the pam_unix module will constantly be returning errors from the password history code due to the file being missing.
Treat your opasswd file like your /etc/shadow file because it will end up containing user password hashes (albeit for old user passwords that are no longer in use):
chown root:root /etc/security/opasswd
chmod 600 /etc/security/opasswd
Once you've got the opasswd file set up, enable password history checking by adding the option "remember=<x>" to the pam_unix configuration line in the /etc/pam.d/common-password file. Here's how I have things set up on my Knoppix machine:
password required pam_cracklib.so retry=3 minlen=12 difok=4
password required pam_unix.so md5 remember=12 use_authtok
The value of the "remember" parameter is the number of old passwords you want to store for a user. It turns out that there's an internal maximum of 400 previous passwords, so values higher than 400 are all equivalent to 400. Before you complain about this limit, consider that even if your site forces users to change passwords every 30 days, 400 previous passwords represents over 30 years of password history. This is probably sufficient for even the oldest of legacy systems.
Once you've enabled password history, the opasswd file starts filling up with user entries that look like this:
The first two fields are the username and user ID. The <n> in the third field represents the number of old passwords currently being stored for the user--this value is incremented by one every time a new hash is added to the user's password history until <n> ultimately equals the value of the "remember" parameter set on the pam_unix configuration line. <hash1>,<hash2>,...,<hashn> are actually the MD5 password hashes for the user's old passwords.
At this point you may be wondering how to get the system to automatically force users to change their password after some period of time. This is not actually the job of pam_cracklib. Instead, these parameters are set in the /etc/login.defs file on most Linux systems. PASS_MAX_DAYS is how often users have to change their passwords. PASS_MIN_DAYS is how long a user is forced to live with their new password before their allowed to change it again. PASS_WARN_AGE is the number of days before the password expiration date that the user is warned that their password is about to expire. The choice of values for these parameters is entirely dependent on site policy.
Note that these parameters are only applied to new accounts created with the default system useradd program. If you use some other mechanism for creating accounts on the system, then you'll have to use the chage command (this is not a typo) to manually set these parameters on your user accounts. And if you use a naming service such as LDAP or NIS for account management, then you're completely on your own.
By the way, if you've ever wondered what all those extra fields in the /etc/shadow file were for, the answer is that they store the password expiration/aging information for the user.
Dictionary attack is used for detecting password.
A dictionary attack is a technique for defeating a cipher or authentication mechanism by trying to determine its decryption key or passphrase by searching a large number of possibilities.
A dictionary attack also exploits the tendency of people to choose weak passwords, and is related to the previous attack. Password cracking programs usually come equipped with "dictionaries", or word lists, with thousands or even millions of entries of several kinds, including:
=> Words in various languages
=> names of people
=> Commonly used passwords etc
However you can use the existence of these dictionary attack tools demonstrates the relative strengths of different password choices against such attacks.
Check user passwords against a dictionary attack
You can be configured to verify that passwords (read as weak password) cannot be guessed easily using Linux PAM module called pam_cracklib.so. It will check the passwd against dictionary words. User is not allowed to set new password until and unless conditions satisfied (i.e. weak password is not allowed).
Open password configuration file according to your Linux distribution. And make modification as follows.
cracklib PAM module is installed by default so no need to install anything. Just open config file:
# vi /etc/pam.d/system-auth
Append/modify as follows:
password required /lib/security/pam_cracklib.so retry=2 minlen=10 difok=6
Debian or Ubentu Linux
First install libpam-cracklib PAM module to enable cracklib support.
# apt-get install libpam-cracklib
$ sudo install libpam-cracklib
Now open config file:
# vi /etc/pam.d/system-auth
Append/modify as follows:
password required pam_cracklib.so retry=2 minlen=10 difok=6
Save and close the file
- retry=2 : Prompt user at most 2 times before returning with error
- minlen=10 : minimum length allowed for an account password is set to 10 characters. This is the minimum simplicity count for a good password. And you are allowed only 2 times using retry option.
- difok=6: How many characters can be the same in the new password relative to the old. User will see error - BAD PASSWORD: is too similar to the old one
- You can also apply following options to compute the 'unsimplicity' of the password.
- dcredit=N : Digits characters
- ucredit=N : Upper characters
- lcredit=N : Lower characters
- ocredit=N : Other characters
Please note that restrictions are only applied to normal users (not to root user).
pam_cracklib.so PAM module,
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: March 12, 2019