I Know Your Password! The Default is at Fault

By Dan Riehl

When you create a new user profile, the historical tendency is to use the IBM supplied default value for the User's new password. The password value is shown on the command prompt as *USRPRF. We know that when this value is used, the user's password will be set to the same characters that make up the name of their User Profile. So, if the User Profile name is JSMITH, the password will also be set to JSMITH.

Well, if IBM set the default to *USRPRF, they must know what they are doing, right? Well, IBM also use to ship the AS/400 and iSeries from the factory at QSECURITY Level 10, which in effect says "No Security". While IBM has now changed to shipping new IBM i systems at QSECURITY Level 40, they have not, as yet, changed the password default for newly created user profiles. In my opinion, there should not be a default value for the User's Password, it should always be a required entry. (i.e. You must specify a value).

A snippet of the the command prompt for the CRTUSRPRF(Create User Profile) command is shown below, with the IBM supplied Password Default Value of *USRPRF. This tells the system to assign the password to be identical to the name of the User Profile being created. This is referred to as a Default Password.

Each year PowerTech publishes their "State of IBM i Security Study". The 2014 PowerTech Study evaluated 233 servers/partitions. You can download your copy of the 2014 Study here. It is a great resource for security administrators.

Here is a quote from the just released 2014 study, courtesy of PowerTech.

"In one interesting statistic in the study, nearly 5 percent of enabled user profiles have default passwords. More than half (53 percent) of the systems in the study have more than 30 user profiles—15 percent have more than 100 user profiles—with default passwords."

The problem of Default Passwords that PowerTech points out in their study is a problem I have also seen in my own security assessments of both large and small organizations. In many instances, it is the company security policy that allows these default passwords to be used. I suggest that the policy that allows for default passwords needs to be revised, so that default passwords are never allowed.

To evaluate your own IBM i system to see what, and how many, User Profiles have Default Passwords, you use the command ANZDFTPWD(Analyze Default Passwords). A printed list of offending profiles will be generated. You may be VERY surprised to see what User Profiles show up in the printed report. These are Users that have a password that exactly matches their UserID.

Why is this a Big Deal?

Let's consider for a moment the pitfalls of using the IBM supplied Password default *USRPRF, thus making the user password the same as the user profile name.

If I know your user profile naming convention(e.g. First Character of the First Name followed by the Last Name), I know everyone's UserID by simply viewing the company employee directory. And I know that, in many cases, a high percentage of these users will have a default password. I just keep trying each userID, one at a time, until I find one with a default password. I'm in!

Let's consider a typical business scenario.

When a new employee is hired, HR, or another appropriate authority sends out an e-mail that says, 'We are pleased to announce that John Smith will be joining company ABC in the position of Payroll Manager. John will start next Wednesday.'.

Before the email even goes out to the company, HR has notified IT of the new employee. The IT group with then provision the new user for each Windows/Unix/Linux server and your IBM i systems. (e.g. Creating new accounts on Windows and IBM i, setting up Email, etc.)

So, we now have a new User Profile on the IBM i, and everyone in the company knows the UserID and Password. We use a naming standard of using the first character from the first name, and first 9 characters from the last name. So, the UserID is JSMITH, and the password is the same.

At this point, any user can log on with the profile JSMITH with the password JSMITH and can view and manipulate all payroll data. After all JSMITH is the Payroll Manager.

But, you may say, "I have the password set to EXPIRED(*YES)". Yes, that's very good. But that only means that during the first sign-on to the system, the password must be changed. Anyone can do that before next Wednesday, when the actual user starts work.

Then, when John Smith does actually log-on for the first time next Wednesday, the system will simply respond "Password not correct for User Profile". After 3, or so, failed attempts, John will call the help desk to reset the password back to the password JSMITH, and Re-Enable the profile. Would you have guessed that the account, and the Payroll system, had actually been compromised by an intruder before John Smith actually started work.

As I mentioned earlier, when I visit IBM i customers for the purpose of performing a security vulnerability assessment, one common vulnerability that I find is that tens or even hundreds of User Profiles have matching (default) passwords. If you are serious about the security and integrity of your system, this problem must be fixed.

You must make a change to your policy on creating and changing IBM i User Profiles. The policy should set in stone that the initial password assigned to the user is never the same as the profile name. This is for the time when the profile is first created, and also any time the password needs to be reset.

I like to use the value *NONE as the password, which means that the user profile, while pre-created for the user, does not allow the user to sign-on. When they need to sign-on for the first time, they can make contact with IT Security or the Help Desk. When you have validated the user is who they say they are, you can provide a one-time password to them and change the profile password accordingly. The purpose of the one-time password is to get the new user signed-on, so they can set the password to a value that only they know. This is also a great time to train the new user on your Profile and Password policies. These would include policies like the penalty in sharing your password with anyone; Policies on storing company data on their PC or Laptop, and the use of Email, USB drives and CD Writers. It is always best to have HR be involved in communicating policies and penalties, but it still falls mainly on IT to make sure the develop the policies are ensure enforcement.

I know that all of our organizations are different, and have different methods of securing passwords. My recommendations here are not to set rules in stone, but to perhaps start you working on a usable security password policy to use in your unique circumstances. We will all have a different approach that works within our constraints and business methods.

Finally, Please, Never make the User Password equal to the User Profile Name.

About the Author

Dan Riehl is the Editor of the SecureMyi Security Newsletter and a Security Specialist for
the IT Security and Compliance Group

Dan performs IBM i security assessments and provides security consulting, remediation, forensic evaluations, and other customized security services for his clients. He also provides training in all aspects of IBM i security and other technical areas through The 400 School, Inc.

Dan Riehl on LinkedIn