Admin Alert: Eliminating Easy-to-Guess User Passwords
August 8, 2007 Joe Hertvik
|
A chronic System i security problem is that without proper system configuration, users can create easy-to-guess and easy-to-hack passwords when they use the PC5250 Change iSeries Password function, the Change Password command (CHGPWD), or the Change User Profile command (CRTUSRPRF) to change their passwords. This week, I’ll look at some simple system configurations you can perform to ensure that user-created passwords are always sufficiently complex for system security. What I Mean By Easily Guessed Passwords Easily guessed passwords include any user password that a middle school student could reasonably guess if they just have a little information about the person signing on. For the purposes of this article, I will focus on how you configure your System i, iSeries, and AS/400 partitions to prevent users from entering any of the following easy-to-guess password types. Default passwords: Where the password is the same as the user profile name (i.e., a user profile name of JOE that has the password ‘JOE’). Honey-bee names: Where the password is equal to the name of something the user holds dear (spouse name, dog name, movie characters, sports teams, etc). Unlucky numbers: Where the password is the same as a significant number in the user’s life (telephone numbers or extensions, birth date, etc). Likealooks: All of the above password types with one or two minor changes to make them “harder” to guess (i.e., ‘JOE’ becomes ‘JOE1’ or ‘J0E’). As I said, these passwords are so easy that a 12-year-old should be able to figure them out and that’s where you need to shore up your i5/OS security. Here are some easy configurations to automatically make your users create more secure passwords. The Well-Composed Password i5/OS and OS/400 password composition rules are defined in the i5/OS system values that start with the literal QPWD* (for example, QPWDMAXLEN, QPWDLMTREP, etc). You can access and change these values on either the green-screen or in iSeries Navigator (OpsNav). As delivered, all password composition rules are turned off, and any changes to the rules take effect immediately for all but one user password change situation. To view and change your composition rules on the green-screen, use the following Work with System Values command. WRKSYSVAL SYSVAL(QPWD*) To change these system values in OpsNav, open the Validation tab on the Password Policy Properties screen. This screen can be reached by following the Security –> Polices –> Password Policy OpsNav path for your target partition. At the bottom of this article, I provide a list of all the i5/OS Password Composition system values and what each value does. You may also want to check out an earlier article by Wayne Evans on Creating Effective Passwords. Wayne’s article contains all password-related system values plus some general principles for defining effective password policies. For this article, I’ll teach by example. I’m going to take the four easy-to-guess password types listed at the top of the article, and demonstrate how to configure your operating system to prevent users from entering each type of password. Where Users Can Change Passwords In most shops, users can change their passwords in the following ways. With one exception, these user-directed password changes all follow the password composition rules that I’m discussing here.
The CHGUSRPRF Gotcha Of these techniques, please note that all bets for controlling password composition are off if you allow your users to change their passwords by using the Change User Profile command (CHGUSRPRF). As a general rule, this command should be restricted only to system administrators. CHGUSRPRF does not enforce password composition rules for password changes, so users can execute CHGUSRPRF to change their password to any value they wish, including the default password. (note: the other techniques do enforce the composition rules). But don’t think that that it’s just application users who use CHGUSRPRF to enter trivial passwords. I once worked in a shop where the iSeries administrator preferred to keep his own password set at the default value for 17 different iSeries and AS/400 machines, which is a pretty serious breach of corporate security, and he always used CHGUSRPRF to make that change. So you have to keep on your toes and you even need to check out those users who are responsible for security. Stopping Default Passwords It’s easy to prevent users from changing their password to the default password, where the password value is the same as the user profile name. This can be done by changing one or more of the password composition settings (the PWD* system values) from their default value. If any of these values are modified, the system will prevent the user from entering their default password as a new password value. However, if you don’t change at least one password composition system value from its shipped status, the user will be able to change the password back to its default. So make sure to activate at least one setting to remove this threat. De-Populating the Honey Bee Population To prevent passwords where the value is equal to the name of something the user holds dear, such as the name of the user’s spouse, dog, or favorite movie character (ex., ‘MELISSA’, ‘BUBBA’ or ‘HANNIBAL’), you can activate the following system values in conjunction with each other to make these passwords harder to guess.
Losing Lucky Numbers Recently, I wrote a column that described how i5/OS can allow user passwords to begin and end with a number. This means that users can conceivably sign on to the system by using their birth dates, telephone numbers, employee ID numbers, etc. To discourage this practice, you can turn on the Limit adjacent digits in passwords system value (QPWDLMTAJC, or Restrict Consecutive Digits in OpsNav), and the password composition rules will not let the user enter two numeric digits in a row when creating a password. Likealooks–Stopping Those Who Are the Same, Only Different Likealook passwords retain the same form as the prior password the user is changing from, but they have one key difference. The new password is usually created by adding or incrementing a number to the end of the old password or by changing one character of the old password for another (i.e., changing a password of ‘JOE’ to ‘JOE1’ or changing ‘JOE’ to ‘J0E’). Likealooks can easily be stopped by turning on the Limit password character positions system value (QPWDPOSDIF or Require a new character in each position in OpsNav). QPWDPOSDIF prevents users from entering passwords in which any of the characters in the new password are in the same position as the characters in the old password. So if I tried to change my password from ‘JOE’ to ‘JOE1’, I would be stopped because the system wouldn’t allow me to enter the letters ‘J’, ‘O’, and ‘E’ in the same position as they were in my prior password. And the Only Problem Is . . . . The one flaw in using system values to control password composition is that the new requirements may annoy your users when they have to change their password. It might even increase help desk calls if some users can’t figure out why the system won’t let them enter the password they want. But since user passwords are usually only changed once every so many months, it is worth the inconvenience to obtain better system security. About Our Testing Environment Configurations described in this article were tested on an i5 550 box running i5/OS V5R3. Many of the commands may also be available in earlier versions of the operating system running on iSeries or AS/400 machines. iSeries Navigator (OpsNav) features were tested with the OpsNav version that is shipped with iSeries Access for Windows V5R3M0. If a command is present in earlier versions of the i5/OS or OS/400 operating systems, you may notice some variations in the pre-V5R3 copies of these commands. These differences may be due to command improvements that have occurred from release to release. i5/OS Password Composition System Values
RELATED STORIES Weird i5 User Profile Sign-On Secrets
|
