Single sign-on -- not a panacea
Tim Landgrave
Published: 19 Sep 2002 13:53 BST
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 organisation 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.
Previous
Did you find this article useful?
91 out of 192 people found this useful
Digg
Slashdot
Del.ici.ous
Stumble
Reddit
