Safeguarding and protecting passwords on IBM i demands moving to a higher level. Carol discusses the benefits and provides guidance on changing QPWDLVL to increase password strength.

There's heightened focus across the IBM i community to improve the power of passwords. That's music to my ears! Here are the considerations you'll have to make when moving the system to a higher password level.

The system value QPWDLVL controls the password formats stored as well as the length and character set available for users' passwords. Changes to this system value will take effect with the next IPL. I'll discuss this system value in two sets: Password levels 0 and 1 and password levels 2 and 3.

Password levels 0 and 1 define that a user's password will have a maximum length of 10 characters and can consist only of uppercase A–Z, numerals 0–9, and special characters #, @, $ and _. The problem with these two levels is the restricted character set. The small number of possibilities of password combinations means that passwords are relatively easy to guess and can certainly be brute-force attacked in a short period of time. The difference between password levels 0 and 1 is in the format of the passwords stored. At password level 1, one of the formats is a very weakly encrypted version that's used when users are connecting to the NetServer. This version is rather easy to decrypt, so it presents a vulnerability to the IBM i. The good news, however, is that the only connections using this password are those coming from computers running Windows 95, 98, or ME or Windows 2000 Server and connecting to the NetServer. These days, it's rare that organizations still have computers using these operating systems. Or if they do, they are not used to connect to the NetServer; therefore, for the vast majority of organizations, they will, at the very least, be able to move to password level 1 (that is, set QPWDLVL to '1') and experience absolutely no issues. The benefit of moving to password level 1 is that the weakly encrypted Microsoft password is no longer stored and, therefore, no longer presents a vulnerability to the system.

If you do nothing else, consider moving to password level 1.

What I would really like you to consider, however, is moving to an even higher level, with password level 3 being your ultimate goal. Here are the benefits of moving to password level 2 or 3.

• Moving the system to one of these levels enables passwords that can be up to 128 characters and can contain any value—uppercase and lowercase letters, numerals, punctuation, spaces, and any special characters. This increases the password character-set tremendously and reduces the chances of having the password guessed (assuming appropriate composition rules are applied) and increases the time of a brute-force attack.
• If you need to, you can keep the maximum length of a password to be 10, but even doing that, because of the greatly increased character-set that the password can contain, you've made it much harder for people to guess a password.
• Password level 2 or 3 also makes the QPWDRULES system value more usable. When using QPWDRULES, you put all of your rules in this one system value (min length, max length, etc. rather than using the individual QPWDMINLEN, for example), but then you can add the value of *REQANY3 - require any 3, so now users have the requirement of using three of the following four: an uppercase, lowercase, digit, or special character in their password.
• Password level 2 or 3 usually makes it easier for the IBM i passwords to have the same requirements as the network password.
• Users will not have to change their password right away unless you force them to. They can use their existing password even after the system moves to password level 2 or 3.

As I've stated previously, an IPL is required to make the new password level take effect. Here's what changes on the IPL:

• The password field on the sign-on screen is different. If you've modified the sign-on display that ships with the systems, you'll now have to modify the DDS (the display specifications) that includes the 128-character password field. See Figure 1.

Figure 1: Here’s the sign-on display after IPLing to QPWDLVL 2 or 3. Notice the increased length of the Password field.

• Prompts for the CRTUSRPRF and CHGUSRPRF commands are changed to allow input of passwords that are 128 chars long.  See Figure 2.

Figure 2: This is how the User password parameter will appear in both the Create and Change User Profile commands at password level 2 or 3.

There are some considerations that you'll want to make prior to making the move to a higher password level. Here's what to look out for and also what has the potential to break:

• If you have any utilities that reset a user's password (perhaps used by your Help Desk, for example), you'll want to modify those to allow for the longer password.
• Connections: In general, all connections should work. By this I mean connections that are made from another server to your IBM i using ODBC, JDBC, DDM, FTP, etc. These connections are typically established with a script that contains the password of the profile being used to connect to IBM i. These connections will work unless the password used is hard-coded to be in mixed case. Let me explain further. At password levels 0 and 1, passwords are stored encrypted in two formats—one all uppercase and one all lowercase—to make it easier to make the move to password level 2 or 3. (As I've discussed earlier, password level 0 has an additional format—a weakly encrypted password used to connect to the NetServer via old clients.) When the system moves to 2 or 3, passwords are no longer "folded" to be all uppercase or lowercase when the password is entered. At levels 2 and 3, it's what you see is what you get. So when the system is at password level 2 or 3 and a connection passes in a mixed case password, the system thinks that it's truly a mixed case password and compares it to what's stored. If the profile's password hasn't been changed since the IPL, what is still stored is a version of the password in all uppercase and another one in all lowercase letters. In that situation, a connection passing in a mixed case password will fail. But if the password contains either all uppercase or all lowercase letters, the connection will be established with no issue.
• End users: The biggest issue with this move is typically educating the end users. When users enter a mixed case password into an IBM i sign-on screen out of either habit (because that's how they enter the password for the network) or ignorance (thinking they're really using a mixed case password), their signon will fail because the system will no longer fold the password to all uppercase and all lowercase at password level 2 or 3. The system will take the password "as is" and, because there's no mixed case password stored, the user's sign-on will fail. So you have to train the users to not use a mixed case password until they change their password for the first time. Truly, this is the biggest issue for the customers that I've seen make the move to level 2 or 3 from level 0 or 1. Typically, they make everyone change their password right away so the training amounts to making sure everyone enters their current password in all lowercase (or all uppercase), and then users can type in a mixed-case password from then on. Admittedly, it can be a mess that first day after the system is IPLed (because all users are affected at the same time), but after that, it's usually not an issue.
• The IBM Security Reference manual advises that all of the systems in your network should be at the same password level. But as I've seen countless times at various clients, it's not an issue to have systems at different password levels.

The ultimate goal should be to get to password level 3 because password level 2 starts storing the old (and weak) Microsoft password again. You might be tempted to jump right to password level 3, but if something's not quite right and you have to move back down to level 0 or 1, it's going to be difficult. If you IPL directly back to 0 or 1, you have to re-assign a password to every user who needs to sign on or make a connection because the password that's stored at level 3 or will work only at level 2 or 3, not 0 or 1. So backing off of level 3 is really a two-step process: first go to level 2, then go to level 0 or 1. The better approach is to go to level 2 and hang there until you know all of your connections are working. Once you know all your connections work, then IPL to level 3. If you have to back down from level 2 to 0 or 1, there's a password stored that will work for each user at those levels (assuming that it's a max length of 10 and doesn't use special characters that aren't supported at level 0 or 1).

Final Thoughts

QPWDLVL 3 is where you want to be because, at that level, the only password that's stored is the one that works at password levels 2 and 3. You'll just want to get there in steps.