Many recent hacks have accessed networks and then accessed databases by obtaining administrator credentials (user IDs and passwords). Databases of emails and passwords are also being stolen from breached organizations. Carol discusses how to reduce password abuse.

You may not realize it, but many of the organizations recently breached are large IBM i shops. The general public never knows whether our beloved IBM i was breached because that information is never published. But to dismiss the possibility out of hand and ignore steps that you can take to protect your organization and—more importantly—the data on your IBM i systems is putting that data at significant risk. This article focuses on protecting passwords since exploiting stolen credentials (user IDs and passwords) is one method being used by hackers to gain access to data.

Eliminate Passwords

One way you can eliminate hackers from swiping your credentials is to not use passwords on IBM i. In other words, implement single sign-on (SSO) with Kerberos tickets. Kerberos tickets time out, so even if they could be stolen, they wouldn't be any good to the hacker. Note that I said single sign-on using Kerberos. Many single sign-on solutions simply propagate passwords to all applications and operating systems. Not only does this not help the situation, it worsens the situation, ensuring that all passwords—everywhere—are the same. So if the hackers grab an administrator's password, they have been given access to every system and application to which that admin has access. Natively implemented single sign-on on IBM i uses Kerberos tickets—not passwords—for authentication, so the risk of having administrator passwords stolen and used to gain access to IBM i is eliminated with this implementation.

Implement SSL

Even when implementing single sign-on using Kerberos, there are pros and cons, so single sign-on isn't for all organizations. So what are your options if your organization is going to continue to use passwords? One option is to make passwords unreadable. That is, make all connections over an encrypted session. For those of you using iAccess to connect to IBM i, this is a fairly easy task, especially for administrators. If you use a digital certificate from a well-known Certificate Authority (CA), then the setup consists of assigning that certificate to the servers in Digital Certificate Manager (DCM) and then configuring your connections to use SSL. That configuration can be done in one step by configuring iNavigator to use an SSL connection. All other connections (for example, 5250 emulation, ODBC, data transfer, and others) default to using the setting defined in iNav. For step-by-step details, see the video "Introduction to Configuring iAccess Servers to Use SSL."

If you choose to use a self-signed certificate or a certificate from a CA not in your clients' list of trusted signers, then you'll also have to import the CA's certificate to every client. That is best done through your desktop management software (assuming you have that). If you don't, you'll have to import the certificate and configure each client. If the thought of doing that for your entire organization is overwhelming, start configuring all administrator workstations and then get the desktop image that's used for new PCs configured with the right certificates and configuration. At least that way, the most powerful credentials (and most useful to a hacker) will be protected and over time your entire organization will be protected.

Even if you're not using SSL, most other companies' emulators are enabled for use over SSL. Check with those vendors for configuration options.

Finally, consider switching to iAccess for the Web, which runs in a browser and can easily be configured to use an encrypted session (that is, use HTTPS.) Switching may be a more viable solution than configuring the desktop software of all users in your organization.

Bypass Sign-On

While ensuring all of your communications run over an encrypted session, the one thing you can do to eliminate passwords from flowing in cleartext when using 5250 emulation is to use the bypass sign-on option in your emulation configuration. Users will still have to enter their user id and password in the iAccess sign on dialog but that password is not sent over the network in cleartext. When the user ID-password combination is valid, the user will be taken right into the screen they normally see after signing on to the 5250 Telnet sign-on display. In other words, the 5250 sign-on display will be bypassed, and the user's password will not be sent over your network in cleartext. A word of warning: One of our clients changed their users' configuration without telling their end users and basically freaked them out! They couldn't figure out why they didn't need to sign on again. So while you may be thinking you're doing your users a favor by not requiring them to sign on again (and protecting passwords at the same time) you'll want to be sure to educate (i.e., warn) them prior to making the change!

Change Passwords More Often

I am appalled at the number of administrator profiles I see whose password expiration interval has been set to *NOMAX, meaning that they don't ever have to change their password. Shame on you! Of all of the profiles on the system that need to have their passwords changed regularly, it's administrators' passwords! If they're stolen, they can be used forever. Administrators' passwords should be changed more frequently than end users'—at least once a month. Don't wait for the typical 90-day expiration interval. Change all administrators' profiles to have a password expiration interval of 30 to ensure you don't forget. And don't succumb to temptation and use the Change User Profile (CHGUSRPRF) command to change it back to the original password. Administrators' credentials are the most valuable to a hacker; don't make their exploits easier by giving them a perpetually valid user ID-password combination!

Use Complex Passwords

Along with changing your password regularly, I strongly encourage you to use complex passwords—that is, passwords that contain a minimum of eight characters, at least one digit, and uppercase and lowercase letters. Wait a minute, you say, IBM i can't do mixed-case passwords. Yes it can if you move your system to QPWDLVL (password level) 2 or, preferably, 3. We're seeing an increasing number of our clients move to password level 2 or 3 to take advantage of the increased character-set allowed by these levels. Not only do they support uppercase and lowercase letters, but they support any special character, all punctuation, and even blanks, making the task of guessing a password significantly more difficult over the reduced set of uppercase A-Z, 0-9, and special characters #, _ $, and @ supported by password levels 0 and 1.

At the very least, you should move off of password level 0 unless you have clients that are connecting to the NetServer running on your IBM i using an old client. By "old" I mean Windows 95, 98, ME or Windows 2000 server. If you're no longer using these clients or you don't use the NetServer, then there's no reason for your systems to remain at password level 0. Set the QPWDLVL system value to '1' and it will take effect with the next IPL.

Use Different Passwords

OK, I realize that this is going to be the most controversial recommendation I'm making, but it's a real recommendation. If, as an administrator, you use different passwords for each system you sign on to, the risk of a hacker abusing stolen credentials will be limited to one system. There's no technology that can enforce this. It's your determination to do everything possible to protect your organization that will have you implementing this suggestion.

Passwords in Your Personal Life

The workplace is not the only place you should be concerned about the safety of passwords. My last suggestion of using different passwords goes for your personal sites as well. I can hear you groaning, but I'm very serious about this. Hackers are increasingly stealing email addresses (which is usually your user ID) and passwords. They want nothing more than these credentials to work on other sites. If you use different passwords, they may have half of the equation to get onto another site but not your password. The other recommendation that will make you groan is to use complex passwords, especially for anything having to do with your finances. If you can't remember the password for each site, put them into one of the plethora of password vaults that securely store your passwords. And if all else fails, write them down and lock up the piece of paper! (Yes, I did just say to write down your passwords, but I'm talking about passwords used for personal sites, not your workplace passwords!)

Final Thoughts

We're not going to stop the hackers, but there are things that we can do to make their efforts more difficult and cause them to direct their attack somewhere else. Following this advice about passwords will help in the fight.