Here are the methods to fix the 8 common IBM i password security mistakes that your organization could make.
IBM i Password Mistake #1: Making IBM i passwords too short
The problem: Many IBM I shops set their Password level system value (QPWDLVL) to level ‘0’ or ‘1’. This setting restricts password lengths to 10 characters or less, using a restricted character set (the capitalized letters A-Z, the numbers 0-9, and the characters ‘$’, ‘@’, ‘#’ and ‘_’). Using a short password length with limited characters allows for easy-to-guess passwords.
The solution: Move from using 1 to 10-character passwords to using 128 characters or fewer passphrases. Passphrases can include most keyboard characters (including spaces and other non-alphabetic characters) that are more difficult to crack.
On the IBM i, you can change your system to accept longer passphrases (up to 128 characters long) by doing the following:
- Change your QPWDLVL system value to ‘2’ or ‘3’. The change will allow passphrases up to 128 characters long. (Note: changing your QPWDLVL value may have other effects on your system besides allowing longer passphrases. Be sure to consult IBM’s Planning password level changes Web page for other considerations when changing QPWDLVL.
- Change your Minimum length of passwords (QPWDMINLEN) and Maximum length of passwords (QPWDMAXLEN) system values to a password length range greater than 10 characters long. To set a password length range between 10 and 16 characters, for example, set QPWDMINLEN to 10 and QPWDMAXLEN to 16.
- Add the *REQANY3 value to your Password Rules (QPWDRULES) system value. *REQANY3 specifies that any new passwords must contain at least one character from three of the following four character groups:
- At least one uppercase alphabetic character (A-Z)
- At least one lowercase alphabetic character (a-z)
- At least one numeric character (0 – 9)
- At least one unique character that isn’t numeric or alphabetic, including the space character
Longer passphrases containing more varied characters, which result in harder-to-guess passwords versus the standard ten-character or fewer passwords used in many IBM i shops.
IBM i Password Mistake #2: Giving hackers unlimited opportunities to sign in
The problem: Many IBM i shops don’t restrict the number of tries an unauthorized user can use to crack another user’s password. This hole in security results in excessive or unlimited sign-on hacking attempts.
The solution: Set your security system values so that unauthorized users only have a limited amount of tries to guess a user password, before the user and the device used are disabled in the system. Do this by setting the following IBM i sign-on system values.
- Set the Maximum sign-on attempts system value (QMAXSIGN) to ‘3’. A user typing in the wrong password will have only three attempts to enter the correct password before the system takes action.
- Set the Action When Sign-On Attempts Reached system value (QMAXSGNACN) to ‘2’ (Disable profile) or ‘3’ (Disable device and profile). After three failed sign-on attempts, QMAXSGNACN will disable the IBM i profile, under the suspicion that is possibly being hacked (settings ‘2’ or ‘3’) as well as disabling the device the unauthorized user is using (setting ‘3’ only).
Setting these system values only gives unauthorized users a limited number of tries to guess a known user’s password.
IBM i Password Mistake #3: Automatically creating virtual devices for anyone signing on to the system
The problem: This mistake allows TELNET and pass-through users to sign on to an IBM i system unlimited times, using a virtual device (a device description that has no connection with a physical piece of hardware). When the Automatic Configuration of Virtual Devices (QAUTOVRT) system value is set between 1 and 32500 (the number of virtual devices that can be configured), the system will automatically create or assign a virtual device for any TELNET or pass-through user attempting to sign on. When QAUTOVRT is set too high, unauthorized users have an easier time trying to break into your system, because the system will keep configuring devices for them to keep signing on with, up to the QAUTOVRT limit.
The solution: You can limit virtual device creation by setting QAUTOVRT to ‘0’ or a more manageable number. When QAUTOVRT is set to ‘0’, the system will not create any virtual devices for TELNET or pass-through users. If you want the system to auto-create some devices for new users signing on, set the number to a higher more manageable level (such as 1000). Setting QAUTOVRT properly limits the exposure an intruder has to automatically create TELNET devices on your system.
IBM i Password Mistake #4: Letting your users use default passwords
The problem: A default password occurs when the user’s password is equal to the user profile name (ex., the QSECOFR user profile has a password of QSECOFR). A security risk like this can be deadly if a user profile with All Object authority (*ALLOBJ) has a default password. Default passwords are frequently set up for IBM supplied users (i.e., QSECOFR, QSYSOPR, QSRV, etc.) as well as for regular user profiles. It’s easy for an unauthorized user to gain access to your system by finding a user profile that has a default password.
The solution: Locate and change any user profiles that have default passwords. We can accomplish this through the following methods:
- Use the Analyze Default Passwords (ANZDFTPWD) command to detect, disable, or expire default password user profiles. ANZDFTPWD can be run with one of three parameters. A parameter of *NONE lists a report of users with default passwords. Running it with the *DISABLE parameter automatically disables any user profile that has a default password. Using the *PWDEXP parameter expires all user profiles with default passwords, such that the user must change the password the next time they sign on.
- Check the passwords for IBM-supplied user profiles, such as QSECOFR, QSYSOPR, QPGMR, etc.). Several IBM-supplied user profiles use a default password. Click here to find a list of IBM supplied profiles that have known passwords. Go through that list and make sure these profiles have more complex passwords or passwords equal to *NONE, so they can’t sign on. It would help if you also disabled any IBM supplied ‘Q’ user profiles that aren’t being used regularly. Users should not sign on to the system and do work with an IBM supplied ‘Q’ user profile.
IBM i Password Mistake #5: Allowing group user profiles to have a password
The problem: IBM i group profiles are intended to allow users to obtain authorities for a group of users. When a user joins a group profile, they automatically assume the authorities associated with that profile. When the user no longer needs those group authorities or leaves the company, you can delete their profile or remove them from the group. If you allow a group profile to sign on to the system, there is no easy way to cancel its group membership or revoke its authorities without also affecting the other users who are members of that group. Many shops make the mistake of allowing group profiles to sign on to an IBM i system. Worse, if a hacker discovers the password for a group profile, they will automatically have the group profile authorities.
The solution: Don’t allow users to sign on with group profiles. Change the password for all IBM i group profiles to *NONE and disable the profile so that no one can log on using the group profile.
IBM i Password Mistake #6: Allowing common words to be used in passwords
The problem: People use common words or easily guessable words to use in passwords. Some hackers use dictionaries of common words when trying to guess a password. Using a common word makes it easier to find a user ID password.
The solution: Eliminate the exclusive use of whole words in a password. Your password rules should exclude common words, such as ‘hello’, ‘welcome’, ‘password’, or a user’s first or last name. A good template for accomplishing this is by doing the following:
- Add the *REQANY3 value to your QPWDRULES system value, as shown in mistake 1. The change will force the user to use both upper- and lower-case characters, add a number, or add a unique character to a password, removing the use of a common word by itself from password creation.
- Use the Restricted Characters for Passwords system value (QPWDLMTCHR) to remove vowels or ‘Wheel of Fortune’ letters from a password. Use QPWDLMTCHR to restrict your users from using any vowels in your passwords (‘a’, ‘e’, ‘i’, ‘o’, ‘u’, ‘y’), preventing common words from being used. Alternatively, you can employ QPWDLMTCHR to prevent users from using the most popular Wheel of Fortune letters (‘r’, ‘s’, ‘t’, ‘l’, ‘n’, and ‘e’) in a password. Either technique will create harder to guess passwords.
IBM i Password Mistake #7: Not restricting user passwords with IBM i password composition rules
The problem: Many shops don’t put any restrictions on the use of passwords, allowing users to create easy to guess passwords.
The solution: Using IBM i password composition system values, review and set up specific password rules on what types of passwords users can enter. Some of the restrictions you can set up include:
- The Restricted Characters for Passwords system value (QPWDLMTCHR) allows you to specify characters that cannot be used in a password (see Mistake #6 for ideas on using QPWDLMTCHR).
- The Restriction of Repeated Characters for Passwords system value (QPWDLMTREP) prevents users from repeating the same character consecutively in a password, eliminating simple passwords such as 11111111, bbbbbbb, aaaaaaa, etc.).
- The Restriction of Consecutive Digits for Passwords system value (QPWDLMTAJC) prevents users from entering dates, addresses, or other numbers in a password (ex., a01292019, addr7620).
- The Required difference in passwords system value (QPWDRQDDIF) prevents users from reusing old passwords for a limited number of password changes. Users can be l from using previously used passwords for the next 4 through 32 password change cycles.
There are many restrictions you can put on user password creation. Check IBM’s list of system values dealing with passwords to review all the limits you can apply to user-created passwords.
IBM i Password Mistake #8: Having the Help Desk change your user passwords
The problem: Users call the Help Desk when their IBM i password expires. The Help Desk tech “helps” the user by changing their password for them. In the process, the Help Desk tech creates a security breach by resetting and learning the user’s password.
The solution: There are two solutions to this problem.
- Create a program or command to change and expire a user profile’s password. Write a password change program for the Help Desk such that the Help Desk can change a user’s password, but the program automatically expires the password, and the user must change their new password the next time they sign on. This allows the Help Desk to reset passwords while forcing the user to enter a new password immediately.
- Implement an IBM i Self-Service Password Reset system, such as SEA’s iSecurity Password Reset. Similar to a website or mobile password reset procedures, IBM i self-service password reset programs allow the user to change their password after the user has identified themselves to the system. The user can change their passwords themselves without any outside help.