A few years ago, I toured a new customer’s administrative offices. Afterward, I asked my guide from the IT department whether users complained about having to remember different passwords for all the systems they used. He responded with a puzzled look, a question (how did you know that we have a lot of administrative systems?), and a comment (they used to complain, but they don’t anymore). I explained that I understood why they didn’t complain anymore about the passwords—they had solved their recollection issues by placing Post-it Notes all over monitors complete with the IDs and passwords for each of the systems accessed!

I recently returned to the same organization on a different assignment. When I sat down with one of the longtime administrative assistants, I noticed that the Post-it Notes were gone. When I commented about the lack of password reminders, the assistant spoke in glowing terms about the positive effects of the new single sign-on system implemented in the past year. She then proceeded to type her password—which was the word “password”—to access the work order system to allocate several thousand dollars to the new project I was managing.

One step forward, two steps back
Single sign-on (SSO), the Holy Grail of directory services, has the potential to solve many vexing application development and usability issues.

Its ability to allow access to all of one’s corporate assets with a single ID and password combination is appealing. It makes development simpler, as the developer can write code that relies on the directory’s user and group management features rather than developing unique user management systems for each application. SSO reduces the number of help desk calls from users wanting password resets because they forgot a password. It also makes it simple to disable a terminated or rogue user’s access to all corporate applications by disabling a single account.

Unfortunately, it also makes it more difficult for security administrators to protect corporate assets. With SSO, a hacker or disgruntled employee needs only a single ID/password pair to access all of a user’s data and all of the corporate data for which that user has access. For this reason, CIOs need to make sure that they have a well-understood and strictly enforced password policy boasting three essential elements: selection/expiration requirements, how external password access impacts the enterprise, and the use of multiple identities.

Password selection and expiration issues
The most critical elements of any password policy are the selection and expiration requirements for a password.

Users should be told not to use any part of their first name, last name, or username in a password. They should avoid common names or known names, such as their spouse, significant other, or children. The same holds true for common and known dates like birthdays, anniversaries, ZIP codes, etc. Furthermore, passwords should have a minimum length of six characters and include a combination of uppercase and lowercase letters, numbers, and symbols—at least three of the four if not all four.

The system policy should force password expiration at least every 30 days and whenever an employee changes positions within the company. This last point is critical. It’s not uncommon (although also not acceptable) for coworkers in the same area to know each other’s passwords. When a coworker is promoted or moved to another department, you’re asking for trouble if that person’s prior office mates can get access to new data or systems because of their knowledge of prior passwords. When users change their passwords, tech leaders should encourage employees not to use numerical sequences—i.e., if a current password is AjSkDl*1, then don’t make that new password AjSkDl*2.

Most operating systems that support single sign-on for applications also have some ability to enforce password rules (although it typically isn’t turned on by default). These system enforcement policies typically check password length, character selection, and numerical sequencing, and then enforce expiration rules. Unfortunately, systems can’t enforce the remaining restrictions—only IT can.

The use of passwords for internal and external services
Unfortunately, another element of the password policy that needs to be advocated but can’t be enforced technically is the use of passwords on external sites.

Most employees have their personal mail and instant messaging accounts, as well as IDs and passwords, established on sites around the world. The natural tendency is to make life easier by using the same ID and password on all. And they perhaps want to make life even easier by using their corporate ID and password. This practice should be actively discouraged.

Employees should be made aware that using the same personal ID and password on multiple external sites makes desktop data extremely vulnerable and can potentially compromise corporate data. Many companies have a provision in the employment agreement that allows termination of an employee if the company’s systems are compromised using that employee’s ID. Although somewhat draconian (and rarely enforced), the provision is a very good way to get your employees to recognize the importance of the recommendation.

The use of multiple identities
A third required element of any password policy is giving key employees multiple ID/password pairs.

For example, network administrators should have at least two IDs—one for use when performing network management tasks and another for using applications not directly related to managing the network.

Think of the multiple IDs as keys on a key chain—there should be one for the employee’s office and another for the data center door. Many will argue that this defeats the purpose of having SSO in the first place. I disagree. I think that it makes SSO palatable in most organizations that value security of corporate data over the convenience for their employees.

The next challenge: Federated credentials
With both Microsoft (with Passport) and Sun (with the Liberty Alliance) adding the ability to federate credentials, the password and ID issue clearly has the potential to become more complex and worrisome. Once an enterprise provides internal users credentials to access another company’s data (whether it’s a client, partner, or customer), there’s going to be an even larger potential for liability and much more exposure.

Security policies like password selection should be seriously reevaluated in the coming months to meet the challenge of the new federated ecosystem. Having internal policies in place and enforced will give CIOs one less thing to worry about in light of this next major challenge.