The Beauty of IBM i Architecture: Passwords

The beauty, or power, of how IBM i has been architected is reflected in the storage of passwords – or I should say the lack of storage of passwords! What’s stored is a hash derived from an algorithm for which one input is the password. In other words, when a user’s password is set – either when the profile is originally created or when the user changes their password – the password is used as one of the inputs into a hashing algorithm and it’s the resulting hash – not the actual password - that is stored.

Why is this beneficial?

You cannot decrypt the hashed value to determine the original password value. When the profile provides a user id and password to authenticate, the same hashing algorithm is run and the hash values are compared to determine if the profile and password are a valid combination.

In addition, there’s no password file to attack as there is on other operating systems. The password hash is stored in an internal object that cannot be accessed by non-operating system programs.

As already noted, the hash cannot be decrypted to get back to the original password. That said, a brute force attack can be made against a single profile using the QSYRUPWD API as it does return a version of the hashed value (NOT the actual password.) The intended use of this API is to allow software to securely replicate passwords to another partition. How do you protect yourself from this brute force attack? Several ways:

• The API requires the profile running it to have *ALLOBJ and *SECADM special authorities. Obviously, only a handful of users should have this much power. 
• The API defaults to *PUBLIC *EXCLUDE – leave it that way!
• Implement passphrases. The stronger and especially, the longer, the password, the more time it’s going to take for a brute force attack to be successful. (See Figure 1).
• Move your system to QPWDLVL 3, or QPWDLVL 4 if running IBM i 7.5. QPWDLVL 4 uses a stronger encryption algorithm to create the hash value.  But more than that, these password levels don’t store the hashes from the weaker passwords set at lower levels.  QPWDLVL 0-2 store multiple versions of the hash to facilitate going backwards from a higher to lower level. (See Figure 2) These hashes are inherently more vulnerable because they’re generated for a password that has a very limited character set and length vs the unlimited character set and potentially longer length associated with a passphrase. 

Figure 1: Description of each password level as of IBM i 7.5

More about QPWDLVL 4:

• Password level 4 requires users connecting via ACS to be at ACS level 1.1.9.0 or higher. 
• DDM connections that specify the SECURELOC parameter as *VFYENCPWD will likely fail
• All APPC jobs that specify a user id and password will likely fail
• Using the QSYRUPWD at one password or release level and then attempting to set the profile using QSYSUPWD on a different password or release level will fail unless special PTFs are applied.

See the documented security changes for IBM i 7.5 for more details.

Figure 2: Hashes stored at each password level

Figure 2 shows that multiple forms of the hash are stored at all levels except level 4. This is to facilitate moving between the various levels. Moving from 0 or 1 to level 2 is the most complex move as you must ensure that connections coming from another server (IBM i, Linux, Windows, etc) have a valid password for the level you’re moving to and you must also  educate your users on how to sign on after the system is IPLed to QPWDLVL 2.

Many organizations allow users to have the same password across their network. Often, the password rules for initially signing in to a VPN or a PC require a mixed case password. So users – out of habit – enter their IBM i password in mixed case as well. What they don’t realize (and don’t need to) is that the operating system is taking whatever password is entered at password levels 0 and 1 and folding it – that is, making the password all one case. Then the hashing algorithm is run and the hashes compared. The challenge after the IPL to QPWDLVL 2 and prior to the user changing their password is this: the system no longer folds the password entered by the user and the mixed case version of the password is used for authentication. But … until the user changes their password after the IPL to level 2, there is no mixed case password stored. So if the user enters their password in mixed case, the authentication fails. To successfully sign on, users must enter their current password in either all lower case letters or all upper case (both are stored.) User will have to continue to do so until they change their password.

While the system does not automatically require it after moving to password level 2, many organizations require users to change their password the first time they sign on after the IPL, so that the hassle/confusion is only experienced once. This also allows the organization to enforce new password composition rules.

As you move to higher passwords, the password hashes for the lower levels are no longer generated. And as noted previously, your goal should be to get to level 3 or preferably 4 to ensure the hashes generated for these weaker password variations aren’t retained.

Summary

IBM has provided a password architecture that is very difficult to crack – even with a brute force attack. But like many features of the IBM i architecture, we must use it. If you need help moving your system to a higher password level, please contact us for assistance!

Contributed by:
Carol Woodbury
IBM i Security SME
Kisco Systems