Admin Alert: Placing Additional Restrictions on i/OS Passwords
Published: September 8, 2010
by Joe Hertvik
i/OS password security is very robust and you can set up a number of password composition rules by using it. But sometimes you need to step outside the normal boundaries of password system values and enforce additional restrictions that can't be created only with standard i/OS password security. That's where a password approval program comes in handy.
A password approval program is a custom-written program that runs after a newly created user password has been validated by your normal password security system values. An approval program is valuable in that it can add organization-specific password validation tests to your system. If the new password doesn't pass the additional tests specified in the approval program, the program can force the user to enter another password that does follow your custom-designed rules.
Here are some of the more common uses for a password approval program:
- Preventing user passwords from containing the user profile name in their password (i.e., stopping user JOEH from entering a password called JOEH1).
- Preventing a user from using a variation on their current password for their new password (e.g., a user who changes a password from PUPPYDOG1 to PUPPYDOG2).
- Creating a tiered-password setup where different users are required to have different length passwords. In my shop, we had a requirement to increase user password lengths from a 10-character maximum password length to a 15-character minimum length. However, some of our users ran critical Windows client software that could only sign on to our i/OS system by using a six- to 10-character password. We used a password approval program to limit those users to using a shorter password while everyone else had to go to a 15-character minimum password.
- When the password is required to contain a number, stopping the users from ending their password with a number. This can break up proper word passwords by requiring a number to be inserted in the middle of the password (i.e., the user can't enter PUPPYDOG1 but they can enter P2PPYDOG).
Creating a password approval program is easy. You can do it by executing the following three steps.
1. Retrieve sample password approval program code from IBM and read IBM's description of the process. You can find a good sample program at IBM's password approval Web page in the IBM i 6.1 Information Center. After reading this page and compiling the program, you'll have a good starter program that can be modified for your own password control needs. There are two sample approval programs available on the IBM page. One of the programs is used when you list the name of your approval program inside the Password Validation Program system value (QPWDVLDPGM), while the other program is used to validate passwords when QPWDVLDPGM is set to *REGFAC (which tells i/OS to use the program registration facility to locate the name and location of an approval program). This article is geared toward using the program registration facility sample code, because that code can process more information about the password being created, which might allow you to do more with the program.
After creating your program, it's important to always compile the approval program into the QSYS library. Since this program will become part of your sign-on process, compiling it to QSYS ensures that it will be immediately available in the event of a complete disk failure where you have to reload your entire system.
2. Register your password approval program with your system's password validation exit point. This step links your approval program with the system's password validation routine. After running all of the validation tests specified in the password control system values, the system will examine the Validate Password exit point. If your program is specified as an exit program, i/OS will run your validation routine against all new passwords and reject improperly formatted passwords, as necessary.
You can register your new password approval program as a password validation exit point by running the green-screen Work with Registration Information (WRKREGINF) command. On the Work with Registration Information screen, page down to the QIBM_QSY_VLD_PASSWRD entry, the exit point for the password validation process.
Place an "8=Work with exit program" in front of that entry and you'll see the Work with Exit Programs screen. Take an option "1=Add" on this screen and enter the name and library of your password approval program, and that program will now become the exit program for password validation.
3. Activate your password approval program by changing the password validation program system value (QPWDVLDPGM). You can do this by running the following Change System Value (CHGSYSVAL) command.
CHGSYSVAL SYSVAL(QPWDVLDPGM) VALUE(*REGFAC)
This setting tells i/OS to run the password validation program from the QIBM_QSY_VLD_PASSWRD exit point that you updated in step 2. The shipped value for QPWDVLDPGM is *NONE and the operating system won't use the exit point program for additional validation until you change it to *REGFAC. At this point, your password approval program will be called every time a user changes his password through the Change Password (CHGPWD) command or through the Change Password (QSYCHGPW) API, and all user password changes will now also be approved or denied according to the criteria in that program. Remember the approval program will only be called after the password has been tested according to the password control system values, so it augments your normal password security rather than replacing it.
More on Programming the Password Approval Program
In IBM's sample program, they provide some routines for using the Send Program Message (SNDPGMMSG) command to send an escape message designating why the approval program rejected the new password. However, in compiling that program on my system, I found that routine didn't give me what I wanted: instant feedback to the user on why their password wasn't acceptable. To provide this capability, I replaced that SNDPGMMSG command in the sample code with a different SNDPGMMSG command that utilizes message ID CPF9898, IBM's general escape message for application programs. The revised password approval code for sending a password violation message to my users consisted of the following code.
SNDPGMMSG MSGID(CPF9898) MSGF(QSYS/QCPFMSG) +
MSGDTA('Your password must be >= 15 +
characters long. Please enter longer +
CHGVAR VAR(&RTN) VALUE('1')
This code sends a general escape message to the external message queue of the calling job (the TOPGMQ parameter equal to *EXT in the SNDPGMMSG command). It then changes the approval parameter to '1' (&RTN) so that the password validation routine will reject the new password. After exiting the custom-written program, i/OS will display the escape message on a Display Program Messages screen that looks something like this:
After the user presses the ENTER key, control will again shift back to the i/OS password validation routine because my approval program rejected the entered password (the &RTN return parameter was set to '1') and the user must try changing their password again. This loop will continue until a valid password is entered that both the password security system values and the password approval program can accept.
The Downsides of Using a Password Approval Program
The biggest downside to password approval programs is that the user's current password and his new password are both passed to the approval program without encryption. This means that if the program is ever maliciously replaced or incorrectly written, passwords could be written to a database file, which would compromise security.
Another downside to approval programs is that since you're using a custom-written validation routine, there's always the danger of making a mistake and possibly hampering your password validation procedure. So make sure that all changes to this program are carefully vetted before putting it into production. Also, depending on what you're using the validation program for, you may need to document the program for your auditors. In one of the examples I cited above where you're using the program to enforce different password length restrictions for different user groups, it may be necessary to document the reasoning for creating a separate program (and possibly provide a copy of the program itself).
Post this story to del.icio.us
Post this story to Digg
Post this story to Slashdot