Blog

IBM i April 2, 2021

While most regulatory standards specify that you should use appropriate password security, they often don’t specify password composition standards. This makes it difficult to know whether your password security and composition rules will create more secure passwords and meet regulatory standards.

Let’s look at what IBM i password security and composition rules you might put in place to meet a regulatory standard, using the Payment Card Industry (PCI) Data Security Standard (DSS) as an example. We’ll look at PCI DSS requirements, how you develop an IBM i standard to meet those requirements, and what changes you can make in your IBM i system to meet that standard. Even though we’re looking at PCI DSS, the methods used here can be applied to creating password composition rules for other standards, such as Sarbanes-Oxley (SOX) and the EU General Data Protection Regulation (GDPR).

Step #1: Look at what the standard says about password security and password composition

The first step is to determine what your obligations are for password security. Here’s what PCI DSS says about user names and authentication.

Always change ALL vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network. This includes wireless devices that are connected to the cardholder data environment or are used to transmit cardholder data. (Requirement 2.1)—This includes IBM i-supplied and third party-supplied user names.
Assign all users a unique user name before allowing them to access system components or cardholder data (Requirement 8.1)—Everyone has their own user profile. No shared sign ons.
Employ at least one of these to authenticate all users: something you know, such as a password or passphrase; something you have, such as a token device or smart card; or something you are, such as a biometric (Requirement 8.2)—You have a choice of which authentication technique to use, even if you just stay with passwords.
Use strong authentication methods and render all passwords/passphrases unreadable during transmission and storage using strong cryptography. (Requirement 8.2) —Passwords must not be retrievable, which has never been a problem with IBM i.
Secure all individual non-console administrative access and all remote access to the cardholder data environment using multi-factor authentication. (Requirement 8.3)— There are several third-party IBM i programs such as SEA’s iSecurity Password Reset that provide two-factor authentication for password changes and sign ons.
Do not use group, shared, or generic IDs, or other authentication methods. Service providers with access to customer environments must use a unique authentication credential (such as a password/passphrase) for each customer environment. (Requirement 8.5)—Administrators, system developers, database admins, and other users who work on the system but don’t consume data, must also have separate user names and authentication. Everyone must be authenticated.

These requirements provide general rather than specific guidance for password creation and authentication. This isn’t unusual. Password requirements for other regulations can also be general.

The key to defining IBM i password compliance lies in matching the standard’s requirements to IBM i capabilities. Matching allows us to determine what changes you’ll need to make to reach compliance. Here are some steps we took to match up PCI DSS requirements to IBM i configurations.

Step #2: Review and implement existing auditor recommendations

Your password security must meet auditor recommendations. While painful, audits and audit violations are valuable tools for shoring up password security and avoiding regulatory fines. Listen to what your auditors say and implement those recommendations.

Step #3: Weed out vendor-supplied default and known passwords (Requirement 2.1)

For PCI DSS requirement 2.1, review and implement the recommendations in IBM’s document on Changing Known Passwords. This document tells you how to secure well-known password entrances into an IBM i server, including disabling default and well known passwords (passwords published on the Internet), setting IBM i supplied profile password values (Q* users) to *NONE, and changing default dedicated service tools (DST) and system service tools (SST) passwords.

Step #4: Everybody gets their own password (Requirement 8.1 and 8.5)

Some organizations use generic user names and passwords for users with the same duties. For example, there may be one Accounts Payable user called APUSER, and three people sign on as APUSER to do their work. This is a poor security practice that will generate an audit point every time. Every user on your IBM i system must have their own user profile and password. This goes double for system administrators, programmers, and security officers who have special privileges on the system.  Don’t share user profile names, especially the QSECOFR profile or any other profile with security office privileges.

Step #5: Use something you know for authentication (Requirement 8.2)

The most practical IBM i user authentication technique is to use a password or passphrase (something you know). IBM i shops usually have too many users to implement a something you have technique, such as using a card reader or USB device for authentication. And while biometric techniques including fingerprint scanning or facial recognition are becoming more common (especially on smartphones), something you are techniques are not practical for widespread IBM i use yet.

Best practices in this area (as defined by the National Institute of Standards, NIST in their Digital Identity Guidelines) are to use passphrase lengths between 8 and 64 characters and the user can use all printing ASCII (RFC 20) characters in a passphrase, including upper- and lower-case passwords, spaces, and special characters.

To make sure your IBM i can support these requirements, you may need to change your IBM i password level system value (QPWDLVL) from level ‘0’ or ‘1’ to level ‘2’ or ‘3’. QPWDLVL level ‘2’ or ‘3’ allows passphrase lengths up to 128 characters and any character is allowed in a passphrase, while the ‘0’ and ‘1’ level require ten-character passwords.

Before you change your IBM i password level to ‘2’ or ‘3’, check out IBM’s Knowledge Center article on considerations for changing QPWDLVL from ‘0’ or ‘1’ to ‘2’. There are several gotchas that can occur with using existing level ‘0’ or ‘1’ passwords at QPWDLVL level ‘2’ or ‘3’.

Also plan for increasing the maximum length of your passwords, as longer passphrases may force you to change applications that display or send passwords. Changing the maximum length from 10 characters to 16 characters, for example, could break custom sign-on screens and cause issues when sending passwords between programs. Evaluate a maximum password length change in conjunction with your applications.

Step 6: Create possible password composition rules

Your password composition rules will set the minimum and maximum password and passphrase lengths, as well as rules for creating harder-to-guess, more complicated passwords. Eliminating harder-to-guess passwords may not explicitly be stated in your standard requirements, but it’s common sense to reduce hacking and your auditors will demand it.

NIST recommends comparing passwords against known lists of passwords that a) have been previously breached, b) contain dictionary words, c) contain repetitive or sequential characters, or d) contain context-specific words such as the user name. While many IBM i shops may not have the software to compare incoming passwords to known lists, it is generally accepted to use the IBM i password composition values shown in Table 1. Many of these settings are defined in the Password Rules system value (QPWDRULES), while other settings are defined in different system values.

Table 1: Commonly used IBM i password composition system value settings

Step 7: Implement two-factor authentication for remote access or as needed (Requirement 8.3)

Research which third-party products can provide two-factor authentication (also known as multi-factor authentication), such as sending an access code to the user (via cell phone or email) that must be entered in addition to their passphrase when signing on. This will handle two-factor authentication for sign on. Also, consider using a third-party IBM i two-factor password reset program, such as SEA’s iSecurity Password Reset, which allows users to reset their passwords using two-factor authentication.

Step 8: Finding out about IBM i non-retrievable passwords (Requirement 8.4)

The IBM i has always stored its passwords in unreadable format. There is no issue with reverse encryption on an IBM i box as there could be on older Microsoft servers. IBM i passwords are never stored on the system. The system uses encryption algorithms to provide one-way encryption and verification for user sign ons. For more information, check out IBM’s tech support note on IBM i Password Encryption.

Step-by-step for password security and composition rules

This example showed the steps you can follow to configure an IBM i system for PCI DSS password compliance. Use this information as a template for evaluating other regulatory standard requirements against IBM i password capabilities. Many of the capabilities discussed here are universal and can be applied to many different auditing situations.

Allow your users to reset their own passwords!!! iSecurity Password Reset automates end-user IBM i password resets using 2-factor authentication, without contacting your Help Desk or a System Administrator. Click here to learn more.