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.
Play video
Have you looked at the product Control-SA from BMC Software www.bmc.com
It addresses many of these issues.
Posted by anonymous on Monday, October 07 2002 05:01 PM