Checking For Default Passwords

By Rich Loeber,

When you create a new user profile, there are a ton of parameter values that you can select from to customize exactly how that profile will work on your system. A lot of us, because of time constraints or ignorance, have a tendency to take a lot of the defaults that IBM’s i/OS presents to us. One of those defaults, unfortunately, is the user profile’s password. Using default passwords is never a good idea, even when you’re rushed for time. This tip will show you an easy way to identify default user profiles on your system so you can get these passwords changed. A recent study I read showed a surprising number of IBM i shops that use at least some default passwords in their day-to-day operations, don’t be one of them.

IBM ships its i/OS with the default value for the PASSWORD parameter on the Create User Profile (CRTUSRPRF) command set to the special value of *USRPRF. When you use this setting, the password for the user profile is set to the same as the user profile itself. So, if I set up a user profile for RICHARD and leave the PASSWORD parameter set to *USRPRF, then the password for RICHARD is going to be RICHARD. It won’t take a rocket scientist for someone who wants to get into your system to be able to figure out how to log on with this in place.

If you’re concerned about this, it would probably be a good idea to change the default setting for the PASSWORD parameter from *USRPRF to *NONE. In my book, having no password is better than having one that everyone will know. You can make this quick change by just running the following Change Command Default (CHGCMDDFT):


If you do this, remember that the next time you upgrade your installed version of i/OS, the setting will get changed and you will have to repeat this process.

Fortunately, i/OS provides you with a nice utility that will let you analyze the profiles on your system and identify any that have the default password in place. The command to do this is Analyze Default Passwords (ANZDFTPWD) and can be found on the SECTOOLS menu. When you run this analysis, a listing of all user profiles with default passwords will be produced on your system. This listing will show the profile status and whether or not the password has expired.

If you want to quickly take care of any current default password profiles on your system, there is a parameter on the command called the ACTION parameter. It defaults to *NONE, which will not take any remedial action. If you choose, you can use either the *DISABLE option or the *PWDEXP option (or both). Selecting these options will immediately disable any profiles that are currently useable that have default passwords in place. The second option will set the password to show that it is expired. Both will stop the user profiles in question from further use.

Obviously, before taking remedial action, it would be a good idea to make a best effort to contact any affected users to let them know that they will have to change the password they are using when this change is made.

Personally, I think IBM should just do away with default passwords completely. They removed security level 10, and I think this falls right into that same category.

If you have any specific questions about this topic, you can reach me at (, I’ll try to answer your questions. All email messages will be answered.

Custom Password Validation Program

By Rich Loeber,

While the IBM i operating system has very good features for controlling password selection, sometimes your password policy just can’t be enforced without additional checking. You may have a list of reserved words that you specifically do not want anyone using as a password. Or, you may have some very stringent requirements that are just not covered by the system values that control password assignment in IBM’s i/OS.

When this happens, the only solution is to code your own password validation routine. This can be coded in any high level language. The operating system passes four parameters to your program, one of which is a single character return code. Once you’ve had a chance to complete your validation testing, just set the return code to the value you want and exit your program. If you set the return code to zero (‘0′), then the operating system will assume that your password is acceptable and the password is updated. The parameters passed are, in order, the new password, the old password, the return code and the user profile for a total of 31 characters.

To tell the operating system that you now have your own password validation program in place, you need to update the system value “Password validation program” (QPWDVLDPGM). It is shipped from the factory set to *NONE. To use your own program, just change this value to your program name and library name. It is recommended that you store this program object in the QSYS library so that it is always saved when you backup your operating system.

Once your program is in place, test it to make sure that it is getting called. Use the CHGPWD command and intentionally use a password that will cause your routine to fail. You will see that a message is displayed indicating that the password rules are not met along with the value of the return code that you used. By varying the return code for different situations, you can give your support team a heads up as to the exact reason for the password failure. While you’re completing your testing, make sure that you process a valid password change to make sure that normal changes are not adversely affected by your new validation routine.

Registering your specific program with the QPWDVLDPGM system value will only work if you are using standard 10 character user profiles and passwords. If you are using the newer long passwords, then you will have to write an exit program and register it using the exit point registration facility. If you take this path, then the QPWDVLDPGM system value must get set to the special setting of *REGFAC and the exit program is registered by the WRKREGINF command. Beware, however, that the parameters for the exit point are very different. There is a good example of the format needed for this exit program in the IBM security guide.

One thing to watch out for in this process is that the passwords, both old and new, are passed to your program without any encryption. So, do not store any values received in a database file as this will compromise security on your system. In fact, you should periodically check this system value to make sure that it does not change and that the program processing additional validation rules remains unchanged. This could easily be abused on your system, so lock up the program object.

If you’d be interested in receiving a sample program for default 10 character password validation, I’ve written one just to test how this works on my system. Let me know and I’ll send the program shell to you. If you have any questions about this topic you can reach me at (, I’ll try to answer any questions you may have. All email messages will be answered.

Password Basics – Password Administration

By Rich Loeber,

There are a number of good practices that you can adopt in the area of password administration that will also help to keep things healthy. First, you should have a procedure in place to disable user profiles for people who have left your company. I normally recommend that the HR department include the IT security officer on all termination notifications. I must admit, however, that this does not always do the trick.

An alternative to this is the use the Analyze Profile Activity (ANZPRFACT) command on your system about once a month. This command will search out the unused profiles on your system and set them to disabled status. There is a variable number of days that you can use, but 30 is a pretty good bet.

You should also require all users to periodically change their passwords. The following system value will help with this:

QPWDEXPITV – “Password expiration interval”

This will force your users to change their password at the interval, in days, that you specify on the system value. Very secure installations may require passwords to change every day, but most business installations can get along just fine with a 60 day cycle, which is what I normally recommend. This is one that is unpopular with users, but if you are going to take security seriously, it is a must.

You should also do a period review of your user profile base. In this review, I recommend that you check for profiles that have permanent passwords assigned. In some shops, the programmers tend to appropriate this right for themselves, but they should be on rotating passwords just like the rest of the user community.

I also recommend that you look at the options offered on the SECTOOLS menu. Space limitations here do not let me go into these in more depth, but take a look and you may discover some interesting exposures on your system. There are also many more system values that you can employ in your quest for the perfect security setup. One last item I like to recommend is a periodic physical inspection of your user community workstations. It is amazing how often this will turn up passwords written down and “hidden” under mouse pads and even posted right on the face of terminals. All the password controls in the world will not overcome this problem. If you find one of these, I would recommend that you revoke the user’s access to the system and wait for them to complain, then go into detail about why their access rights were revoked. They should get the message.

Password Basics – Password Selection

By Rich Loeber,

There is nothing quite so basic in the security arena as a password. The combination of user profile and password, if properly used and administered, can go a long way to establishing sound system security on your IBM i system.

To start with, configuration and selection of your password is important. All those terrible computer hacker movies do have something going for them when they have people guessing passwords. Too many people select a password that is just too easy to guess. (I was actually at a client recently where the password for QSECOFR was set to ‘PASSWORD’!)

There is a good way to deal with this problem on your IBM i. There are two system values that can help you to enforce the selection of passwords that are harder to guess. These are:

  • QPWDLMTCHR – “Limit characters in password”
  • QPWDRQDDGT – “Require digit in password”

By changing the QPWDLMTCHR setting to the value “AEIOU”, you will disallow all passwords that contain vowels. Setting the QPWDRQDDGT value to ‘1′ will require that at least one character position of the password will have to contain a numeric character. Between these two settings, you can almost guarantee passwords that are much harder to guess.

Along these same lines, there are three other system values that you should consider:

  • QPWDMINLEN – “Minimum password length”
  • QPWDRQDDIF – “Duplicate password control”
  • QPWDLMTREP – “Limit repeating characters in password”

I normally recommend that the minimum password length be set to 5 and 6 is even better. The duplicate password control limits how frequently your users can reuse old favorites. Using the maximum value of ‘1′ effectively prevents recycling of favorite passwords by disallowing a password that has been used sometime during the previous 32 password changes. Also, limiting repeating characters will also provide a little more control. I recommend using the value of ‘2′ to simply disallow contiguous repeating characters.

Remember, the whole idea is to eliminate passwords that are easy to guess but not make is so difficult that people never remember their own passwords. There is a fine line here between protecting your system and keeping your users happy and productive.