Admin Alert: Getting Around System i Default Passwords, Part 1
July 25, 2007 Joe Hertvik
|
Since processing time immemorial, i5/OS and OS/400 computers have had problems with default passwords. Default passwords occur when a user password is equal to its corresponding user profile name. They are mostly created by the system’s user creation commands, and i5/OS administrators can spend a lot of time finding and changing these hacker magnets. This week, I’ll examine the dynamics of System i default passwords and how they are created. Today’s article is part one of a two-part series exploring default passwords and their creation, detection, and prevention. This week, I’ll explore the mechanics of how default passwords are created and their consequences. Next week, I’ll look at some best practices for preventing or limiting system exposure to these easily guessed passwords. How Default Passwords Are Created Many default passwords are nasty by-products of using the green-screen Create User Profile command (CRTUSRPRF). These passwords occur because (IMHO) there are flaws in the default settings for two key CRTUSRPRF parameters. When you use CRTUSRPRF’s default settings to create a user profile, you are executing this command with these parameters.
CRTUSRPRF USRPRF(user_profile_name) PASSWORD(*USRPRF) PWDEXP(*NO) By default, the User password parameter (PASSWORD) is set to *USRPRF, which means that the password for a new user will automatically be set to the user profile name. So if you don’t override the PASSWORD parameter with a hard-to-guess password at user profile creation, you are automatically creating a security hole within your system. To compound this problem, the Set password to expired parameter (PWDEXP) automatically defaults to *NO inside CRTUSRPRF. Setting PWDEXP to *NO means that once the user signs on, he will not be prompted to change his password and the default password will remain active in the system. This parameter combination creates an easily guessed password for hackers and internal users who want to make mischief on your system. If an i5/OS administrator has been careless and never changes the defaults when creating new users, any System i, iSeries, or AS/400 box can easily contain a number of active hackable user profiles. Granted, these passwords will eventually expire according to the Password expiration interval parameter (PWDEXPITV) listed in the user profile, but it’s a dangerous and sloppy security policy to leave open user profiles on the system. If the system is not correctly configured, users can also change their passwords to a default password by using the Change Password command (CHGPWD), the Change User Profile command (CHGUSRPRF), or the PC5250 Change iSeries Password function (more on this in the next issue of Four Hundred Guru). So there is a secondary source of default passwords on your system that you need to watch out for. In i5/OS, it takes two steps to solve the default password security issue. First, you need to detect and change (or disable) any existing default passwords on your system to eliminate the risk of hacking, which is the subject of this week’s article. You may also want to set up an auditing technique to find new default passwords as they occur. Second, you need to look at your system settings and modify them to prevent additional default passwords from being generated, which will be covered next week. Detecting and Changing Default Passwords Both i5/OS and the OS/400 operating system contain a special green screen command to list out all user profiles that contain default passwords. This command is called Analyze Default Passwords (ANZDFTPWD) and it can be run in one of three modes for detecting, disabling, and expiring default passwords. First, to produce a list of users who have default passwords, you would run ANZDFTPWD this way. ANZDFTPWD ACTION(*NONE) In this mode, ANZDFTPWD produces a User profiles with default passwords report that details all users who have default passwords. This report contains the following information for each user.
This information is also stored in the QASECPWD file in the QUSRSYS library. So if you decide to run ANZDFTPWD as a scheduled job, you could create a program that reads the QASECPWD file and processes it according to your shop’s needs. Once you have the report, you can make some decisions on what to do with your default password users. ANZDFTPWD provides two options for dealing with default passwords. You can either disable all user profiles with default passwords or you can set all the default password profiles to a status of expired (*EXPIRED), which will force these users to change their passwords the next time they sign on to the system. To disable all system users with default passwords, run the ANZDFTPWD command this way: ANZDFTPWD ACTION(*DISABLE) To expire all default passwords on your system, you would run ANZDFTPWD this way: ANZDFTPWD ACTION(*PWDEXP) However, a word of caution is in order here. I highly recommend that you first review the User profiles with default passwords report or QASECPWD file before taking either of these actions. There may be specific reasons some users have default passwords–I’m not advocating their usage, but sometimes people are allowed to have this capability–or it may cause a major shock to your users and help desk if you disable several user profiles at once. Prudence is called for in handling these situations, and you may need to manually work with each user to decide how to resolve the problem. Is It Any Better with OpsNav? While it’s clear that there is a problem when using CRTUSRPRF to create users with default passwords, what about user profiles and passwords that are created inside iSeries Navigator (OpsNav)? The bad news is that the default password problem also exists with OpsNav-created user profiles. The good news is that the problem isn’t as severe as it is when you use CRTUSRPRF. You create new i5/OS users in OpsNav by right-clicking on the Security –>Users and Groups –>All Users node and selecting New User from the pop-up menu that appears. This brings you to OpsNav’s New User feature, where you can enter the user name, description, password, and other properties for creating a user. By default, the Password entry box is set to Use user name, which will create a default password for your new user if left unchanged. However, one of the differences between OpsNav user profile creation and CRTUSRPRF is that the Set password to expired parameter has been restyled to a check box on the OpsNav New User panel. This check box is labeled User must change their password at next sign-on. When you designate Use user name in the Password entry box, OpsNav will automatically check (turn on) the User must change their password at next sign-on check-box. OpsNav will also gray-out this check box option when Use user name is selected, so that the user will be forced to change their default password the first time they sign on. If you manually enter a different password in the Password box, the User must change their password at next sign-on check-box will be opened again for modification. So while OpsNav creates the same default password security problem that exists with CRTUSRPRF, it moderates the problem by forcing default password users to change their password the first time they sign on. While this isn’t a perfect solution, it limits the problem to users who have never signed on to the system. Once a user signs on, they will have to change their password and their default password problem goes away. Limiting Default Password Exposure If you make no other changes to your system, a good first step in eliminating the accidental creation of default password users is to use OpsNav for user profile creation, rather than using the green-screen CRTUSRPRF command. This is because OpsNav will automatically configure default password users so that they will be required to change their password when they sign on. If you’re still using CRTUSRPRF, you may want to specify procedures to either always enter a unique password for a new user or to always enter *YES for the Set password to expired parameter. However, since the PWDEXP parameter default is *NO, this could be a spotty solution if people forget to change this setting. You may also want to set up a procedure to automatically print out an ANZDFTPWD report (which will also generate a QASECPWD password file reload) every month for review. However, be careful when printing the ANZDFTPWD User profiles with default passwords report because that report by itself may constitute an audit point. The ANZDFTPWD report should only be printed to a secured location, it should not be left lying around for others to discover, and it should be shredded after use. You should also make sure that the QASECPWD file is secured from *PUBLIC use. These recommendations are simple things that you can do to prevent and detect the use of default passwords. Next week, I’ll discuss a few system changes that will further help you win the battle against default passwords. About Our Testing Environment Configurations described in this article were tested on an i5 550 box running i5/OS V5R3. Many of the commands may also be available in earlier versions of the operating system running on iSeries or AS/400 machines. If a command is present in earlier versions of the i5/OS or OS/400 operating systems, you may notice some variations in the pre-V5R3 copies of these commands. These differences may be due to command improvements that have occurred from release to release. RELATED STORIES A Checklist for Creating OS/400 User Profiles, Part 1 A Checklist for Creating OS/400 User Profiles, Part 2 Making OS/400 User Profiles a Little More Secure
|
