My Foo Is Strong

Setting up stronger password policy rules in Linux – Part II

In a previous post we discussed how to setup stronger password policy rules in Linux and found out that any changes we make are not reflected back to existing accounts. So how do we make these changes retroactively apply to existing accounts?

The answer to our question is relatively straightforward. As RHEL is using shadow passwords by default, the chage command can be used to modify an existing account’s aging information. Before we delve into the specifics, we need to refresh some of the requirements that were given to us.

In our previous discussion we were provided with an account policy document that stated passwords must:

• Be at least 8 characters long.
• Use of at least one upper case character.
• Use of at least one lower case character.
• Use of special characters (!,@#$%, etc).
• Warn 7 days prior to expiration.
• Must expire after 90 days.
• Must be locked after 97 days.

Using chage we can complete the last three items. To do so, we we use chage like so:

# chage -m 0 -M 90 -I 7 -W 7 [user]

This command reads, change the login user to have no minimum number of days for password changes (-m 0), allow at most 90 days before a password change is required (-M 90), lock the account 7 days after the account has expired (-I 7), and warn the user 7 days prior to account expiration (-W 7).

But what about the first four passwords requirements for existing accounts? The password policy changes did not affect any existing accounts that already had passwords set. If at any point the user manually changes their password, the new password policies will be enforced and the first four requirements will be met. Realistically though, once the accounts have been modified using chage to have an expiration, the next user password change will force all accounts into compliance. If accounts are needed to be in compliance immediately, a more active approach will require locking the account and requiring the user to change the password.

It’s important to point out that in many cases, there will be accounts that may not fall under this restriction. As an example, many service or application accounts that are are not used for direct logins may be exempted. So long as the account was created before the modification of the password policies, no changes are necessary and the accounts will be left as is. If any of these accounts were created after the policy change it will be important to remember that chage will have to be used to revert the account back to one that is exempt from aging criteria.

In conclusion, Linux has a standard set of tools that can be used to increase the security of an organization’s account data. By re-configuring the system to enforce both account aging policies as well as more stringent password composition rules, a default Linux installation may be enhanced to meet the more realistic needs of today’s organizations.

31. December 2008 by Jason
Categories: Linux | Tags: CentOS, RHEL, security | 1 comment