Image Credit: Ohio State University
Yesterday in my post on Solaris 10 Password Policy Enforcement, I outlined the steps necessary to implement the password requirements that have been decided upon in my system environment. This post will outline the same process on the RHEL5 systems that I admin. While the policy requirements are the same, the implementation is vastly different.
Desired Policy
To re-cap, here is the policy that is to be applied to normal users:
- at least 8 characters in length
- no more than 20 characters in length
- contain at least on letter
- contain at least one number
- forced to change at least every 180 days
- 15 minute lockout after 5 unsuccessful attempts
Implementation Differences with Solaris 10
While there were a couple of pieces of the desired password policy that I was unable to implement on Solaris 10, the ease of which the others were configured wins the game hands down. The PAM module setup on Solaris makes it dead simple to update the policy. All you have to do is to change the various tunable settings. And they are all listed in fairly understandable verbiage, no complex or arcane settings.
On the RHEL5 systems I had to delve into the vagaries of PAM module attributes and ordering. As always, it is important to make backups of any files to protect yourself and allow for disaster recovery. To implement the requirements, I had to edit two files on the system:
- /etc/login.defs
- /etc/pam.d/system-auth
Implementation Process
It is important during this process to recognize that if you set the PAM requirements incorrectly you can get burned to the point that the root user will be unable to login, forcing you to boot into single-user mode to recover or to boot the system from a live cd and revert the authentication files.
Setting the password expiration requirement and length setting
Before we get into this please note the warning notice from the login.defs file manpage on a RHEL5 system
Much of the functionality that used to be provided by the shadow password suite is now handled by PAM. Thus, /etc/login.defs is no longer used by programs such as: login(1), passwd(1), su(1). Pleaserefer to the corresponding PAM configuration files instead.
It is still important to configure the password length in the login.defs file so that we can account for legacy codebases.
- Open /etc/login.defs in your favorite editor
- Set the attribute of PASS_MAX_DAYS to be 180
- Set the attribute of PAS_MIN_LEN to be 9
Setting the password complexity requirements
Now here is where the going gets real interesting. Before we look at /etc/pam.d/system-auth a strong caution
Backup up the file before you alter it and open a backup terminal session as the root user before continuing. If you put the wrong attributes in place or put the PAM directives in the wrong order you will lock yourself, root user and all, out of the system. At that point you have two options: single user mode recovery from the console or use a live cd to boot the machine and revert to the backup after mounting the filesystem. Oh, and it is wise to give yourself a delay with either GRUB or LILO because without the delay you won’t be able to change the boot option to allow the single user mode recovery option.
So, the file involved in this process is /etc/pam.d/system-auth and before I go into some of the nitty gritty, here’s the configuration I ended up using:
#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth required pam_tally2.so deny=6 unlock_time=900 auth sufficient pam_unix.so nullok try_first_pass nodelay auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so account required pam_unix.so account sufficient pam_succeed_if.so uid < 500 quiet account required pam_permit.so account required pam_tally2.so per_user password required pam_passwdqc.so min=disabled,disabled,12,9,9 max=20 similar=deny enforce=users retry=3 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so
The retries requirement is implemented using the following line
auth required pam_tally2.so deny=6 unlock_time=900
The complexity and length requirements are implements using the following line
password required pam_passwdqc.so min=disabled,disabled,12,9,9 max=20 similar=deny enforce=users retry=3
The following line is set to ensure that the retries count is maintained even if the counter for the pam_tally2 module is corrupted
account required pam_tally2.so per_user
References
Rather than go into the details of each individual attribute and how they interact, here are the resources used to develop this ruleset. They contain an large amount of valuable information.
Image Credit: Ohio State University
I was recently handed a baseline policy that was to implemented for all users on the Solaris 10 systems that I support. After a small amount of research I was able to find the various pieces that needed to be altered.
Desired Policy
After discussion between the security officer and the other management level staff, the following policy was decided upon:
Normal User Password Requirements
- at least 8 characters in length
- no more than 20 characters in length
- contain at least on letter
- contain at least one number
- forced to change at least every 180 days
- 15 minute lockout after 5 unsuccessful attempts
Most of the restrictions were fairly basic and could be easily accomplished. The only one that I could find no mechanism for control of in Solaris 10 is the automatic unlock of an account after the specified 15 minute lockout. While it is possible to determine when an account has been locked by looking at the timestamp in the syslog, there is no automated method for unlocking the account after a certain amount of time has elapsed. I suppose it would be possible to write a script to check the entries in the shadow file then grep the syslog then do some math on the timestamp, but honestly I am not worried about it.
Implementation
The implementation process involves editing two files that are key to the functionality of user login security. As always when altering system files it is a good idea to make backups of the originals in case things go wrong. The files involved are:
- /etc/default/login
- /etc/default/passwd
Setting the account lockout (aka Three Strikes)
Generally the default on a Solaris 10 system is to set the account lockout to three password retries before an account is locked. We decided to relax this a little and allow for five retries.
- Open /etc/default/login in your favorite editor
- Search for the line reading RETRIES=3
- Change the line to read RETRIES=5
Configuring the complexity rules
The password complexity ruleset for Solaris 10 is fairly understandable. The rules are defined in /etc/default/passwd and the values to be tweaked are:
- MINDIFF
- MINALPHA
- MINNONALPHA
- MINUPPER
- MINLOWER
- MAXREPEATS
- MINSPECIAL
- MINDIGIT
- WHITESPACE
The desired policy decided upon was to require at least one number and one letter. There was some discussion about special characters, but it was decided to not require any special characters for normal user accounts. Given these requirements the following process is used to implement the complexity ruleset:
- Open the file /etc/default/passwd in your favorite editor
- Set the password complexity tunables to look as follows
MINDIFF=3 MINALPHA=1 #MINNONALPHA=1 #MINUPPER=1 #MINLOWER=1 MAXREPEATS=0 #MINSPECIAL=0 MINDIGIT=1 WHITESPACE=YES
Setting the password expiration and length rules
Configuring account lockouts and password complexity is a great start, however it is not the complete picture. While reasonable complexity rules will allow users to set passwords that they can readily remember, and a flexible lockout value will give some room for fumble fingers, if users are not required to change their passwords every so often then the security of the system can suffer as well.
You also should consider password length. A shorter password, regardless of complexity, is going to be easier to crack from an algorithmic standpoint. This is simply due to the mathematical requirements. The problem is that user’s tend to not like long passwords. As you increase the password length, you increase the likelihood the passwords will use dictionary words (we can account for that as well).
The agreed upon setting for normal users on our systems was 180 days. Unfortunately Solaris 10 uses a setting measured in weeks and not days. What this means is that the setting will have to be slightly longer. The password length was decided to be at least 8 characters and no longer than 20 characters. Also, Solaris 10 has no setting to enable a maximum password length.
- Open /etc/default/passwd in your favorite editor
- Set the value for MAXWEEKS to be the value of number of days divided by 7, rounding up
- Set the value for PASSLENGTH to be the value of the minimum number of characters
Important Notes and Considerations
Password Length
The default algorithm used for passwords under Solaris 10 is crypt_unix. This algorithm is not considered sufficiently secure, even by Oracle. You should investigate using a different algorithm such as MD5 or Blowfish instead. The default will not allow for passwords that are longer than 8 characters. You can set the password to be longer, but all characters after the eighth position will be discarded during the authentication check process.
Retroactive Usage
Changes to the password expiration policy is not immediately retroactive. For the expiration requirements to take effect on existing accounts you will need to initiate a manual password change for the shadow file entry to be updated.
Dictionary Words
When Solaris 10 was introduced one of the changes made to PAM was the ability to use a comma-delimited list of dictionary files to avoid usage of common words during password selection. This can be configured with the DICTIONLIST variable in the /etc/default/passwd file.
Applying lockout to the root user
While this is not the default, you can apply the lockout rule to the root user account by editing the /etc/user_attr file and changing the lock_after_retries value for this user to yes. Be warned this is not recommended since a locked account can only be unlocked by the root user. If your root level account becomes locked then you will need to have an account that allows sudo access or you will end up going to some extreme lengths to re-enable access to the system.
References
Of course, none of this information is really unique. Here is the list of resources I used to put all of this together:
For more commentary on password length, complexity, etc., see a few of these sites:
During the 2010 Tour de France in July, the Lance Armstrong Foundation and Nike worked together to print inspirational messages on the road along the route. This was done using the Livestrong/Nike Chalkbot.
The messages were printed each morning before the stage was to start and they were washed off the road after the stage was completed. The messages were printed using a soy-based material, which was very environmentally friendly.
In the early stages of the race I submitted a small message through the Livestrong website. I imagine that there was a huge response and I have to wonder how many people thought their messages were going to be printed.
On August 10, 2010, 16 days after the race was over I received an e-mail from Nike stating that my message had indeed been printed during the race. The GPS coordinates for my message are: 0.067164,42.950947 and it was printed on July 19, 2010. According to Find Latitude and Longitude website, this is Bageneres-de-Bigorre, France. This would have during stage 15 which ran from Pamiers to Bagnères-de-Luchon.