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 his or her 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, it must know what it is doing, right? Well, IBM also use to ship the iSeries from the factory at QSECURITY Level 10, which in effect says "No Security." While IBM has now changed to shipping new systems at QSECURITY Level 40, it has not as yet changed the password default for newly created user profiles.
Let's consider for a moment the pitfalls of using the default of making the user password the same as the user profile name.
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 Rogers will be joining company ABC in the position of payroll manager. John will start next Wednesday."
Before the e-mail even goes out to the company, HR has notified IT of the new employee, and has provided the information on the level of access for each Windows and System i system. Now, IT performs the new user provisioning, (e.g., creating new accounts on Windows and System i, setting up e-mail, and so on).
So, we now have a new user profile on the System i, and everyone in the company knows the user ID and password. We employ a naming standard of using the first character from the first name and the first nine characters from the last name. So, the user ID for John Rogers is JROGERS, and the password is the same.
At this point, any user can log on with the profile JROGERS with the password JROGERS and can view and manipulate all payroll data. After all JROGERS is the payroll manager.
But, you say, "I have the password set to expired." Yes, that's very good. But that only means that after the first sign-on to the system, the password must be changed. It does not keep me from using the password to log in anytime I want before next Wednesday, when the user actually starts work.
Then, when John Rogers does actually log on for the first time next Wednesday, the system will simply respond "Password not correct for User Profile." After three tries, John will call the help desk to reset the password and profile. Back to the password JROGERS. Which one of us would guess that the account and the Payroll system had actually been compromised before John Rogers actually started.
When I visit System i customers for the purpose of performing a vulnerability assessment, one common thread is that I find tens or hundreds of user profiles that have matching 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 System 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.
I like to use the value *NONE as the password, which means that the user profile, while precreated for the user, does not allow the user to sign on until he makes contact with IT security or the help desk. When you have validated that the user is who he says he is, you can provide a one-time password to that user and change the profile password accordingly. The purpose of the one-time password is to get the new user signed on so he can set the password to a value that only he knows. This is also a great time to train the new user on your Profile and Password policies. These would include policies such as imposing a penalty for sharing your password with anyone, policies on storing company data on a user's PC or laptop, and policies regarding the use of e-mail, 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 policies are enforced.
In Short, never make the user password equal to the user profile name.
Links:
[1] http://systeminetwork.com/author/dan-riehl