Ban Default Passwords with System Value Settings in IBM i 7.2

By Dan Riehl

When you create a new user profile, the historical tendency is to use the IBM supplied default value for the User's new password. The password value is shown on the command prompt as *USRPRF. (Figure 1)

When the value *USRPRF is used to specify the password, the user's password will be set to match the name of their User Profile. So, a User Profile of JSMITH, will have a password set to JSMITH.

A snippet of the command prompt for the CRTUSRPRF(Create User Profile) command is shown below, with the IBM supplied Password default setting of *USRPRF. This tells the system to assign the password to be identical to the name of the User Profile being created. This is referred to as a Default Password. This is a terrible default setting. But, setting a default password can be rejected under the new support discussed in this article.

Why is this a Big Deal?

Let's consider for a moment the main pitfall of allowing Default Passwords. If I know your system’s User Profile naming convention (e.g. First Character of the First Name followed by the Last Name), I know everyone's UserID by simply viewing the company employee directory. (e.g. ASMITH, BSMITH, CSMITH, DSMITH). I also know that, in many cases, a high percentage of these users will have a Default Password. Seems like an easy nut to crack.

Let's consider a typical business scenario.

When a new employee is hired, HR, or another appropriate authority sends out an e-mail that says, 'We are pleased to announce that John Smith will be joining company ABC in the position of Payroll Manager. John will start next Wednesday.'.

Before the email even goes out to the company, HR has notified IT of the new employee. The IT group will immediately begin provisioning the new user for each Windows/Unix/Linux and IBM i server.

So, we now have a new User Profile on the IBM i, and everyone in the company knows the UserID and Password. Payroll Manager John Smith has a UserID of JSMITH and a Password of JSMITH. We use a naming standard of using the first character from the first name, and first 9 characters from the last name. So, the UserID is JSMITH, and the password is the same. At this point, ANY USER can log on with the profile JSMITH with the password JSMITH and can view and manipulate all sensitive payroll data. After all JSMITH is the Payroll Manager.

But, you may say, "I have the password set to EXPIRED(*YES)". Yes, that's very good. But that only means that during the first sign-on to the system, the password must be changed. Anyone can do that before next Wednesday, when the actual user, John Smith, starts work.

Default Passwords open up a world of vulnerabilities and exposures. They should never be allowed.

We’ll now examine how to prevent the assignment of a Default Password. The key to this prevention is found in new support in System Values.

Restricting the use of Default Passwords with System Values

There are two methods to specify password formation rules.

One method is to use the standard QPWD* prefix System Values listed here:
QPWDLMTAJC, QPWDLMTCHR, QPWDLMTREP, QPWDMAXLEN, QPWDMINLEN,
QPWDPOSDIF, and QPWDQDDGT

The newer method, introduced in IBM i 6.1 is to use the QPWDRULES system value.

If the QPWDRULES system value contains the default setting of *PWDSYSVAL, the standard QPWD* prefix system values are used to identify the password rules. If the QPWDRULES system value does NOT contain *PWDSYSVAL, then all password rules are specified as listed in the QPWDRULES system value.

(Note: Additional password rules may also be specified in a Password Validation Program,
           or a Registration entry for the QIBM_QSY_VLD_PASSWRD exit point.)

The QPWDRULES System Value

The system value QPWDRULES is documented here at the IBM i Knowledge Center.

One of the relevant settings for the QPWDRULES System Value in consideration here is the setting *LMTPRFNAME. Using this setting, we specify that the password, in uppercase, cannot contain the complete user profile name in consecutive positions. (User Profile Names are Uppercase)

Examples for the QPWDRULES setting *LMTPRFNAME

Where the User Profile Name is JSMITH

• Password     JSMITH         Not Valid
• Password     BGJSMITH     Not valid
• Password     bgjsmith         Not valid
• Password     MYJsmith       Not Valid
• Password     J1SMITH       Valid
• Password     SMITH_J       Valid

When are Password Rules in Effect?

It has always been the behavior of the system to check password rules only when a user changed their own password using the Change Password (CHGPWD) command or the Change User Password (QSYCHGPW) API.

If you have set the QPWDRULES to include the setting *LMTPRFNAME, a user cannot change their own password to assign a password that contains their User Profile Name in consecutive positions, as shown above.

But, it has also always been the standard behavior for the system to never check any Password Rules when the CRTUSRPRF or CHGUSRPRF commands are used. So, as the administrator or Help-Desk member, you could set a user’s password, totally ignoring password formation rules. So, on CRTUSRPRF and CHGUSRPRF you can set the password to ‘A’ or “DOG’ or ‘CAT’, etc. The rules are not in effect for you, the administrator, to set a password.

Rejecting Default Passwords with Password Rule Support in IBM i 7.2

In IBM i 7.2, a new setting for the QPWDRULES system value can effectively prevent anyone from setting a password to the default value; rejecting a password that matches or contains the UserID. The new setting is *ALLCRTCHG.

The new setting of *ALLCRTCHG specifies to enforce all password composition rules defined in the QPWDRULES system value when setting a password via the Create User Profile (CRTUSRPRF) command or the Change User Profile (CHGUSRPRF) command. This setting has no effect when a user changes their own password using CHGPWD. It is a restriction only when creating and changing a user profile using CRTUSRPRF and CHGUSRPRF commands.

When this new setting(*ALLCRTCHG) is used in conjunction with the *LMTPRFNAME setting,
it is impossible to assign a default password to a user profile.

Going Forward - Check for Existing Default Passwords

In this article we have discussed how to prevent new default passwords from being set. But, you also will want to identify those Users that already have a Default Password. Once identified, you will want to set new passwords for those offending User Profiles.

To evaluate your own system to see which User Profiles have Default Passwords, you use the command ANZDFTPWD(Analyze Default Passwords). A printed list of offending profiles will be generated.

You may be VERY surprised to see what User Profiles show up in the Default Password printed report. These are Users that have a password that exactly matches their UserID. You can also access this command from the GO SECTOOLS menu, option 1.

     

About the Author

Dan Riehl is the Editor of the SecureMyi Security Newsletter and a Security Specialist for
the IT Security and Compliance Group

Dan performs IBM i security assessments and provides security consulting, remediation, forensic evaluations, and other customized security services for his clients. He also provides training in all aspects of IBM i security and other technical areas through The 400 School, Inc.

Dan Riehl on LinkedIn