• be six to eight characters in length.
• contain a nonalphabetical character such as
1 2 3 & , + =
• contain one or more nonalphabetical characters
between alphabetical characters
(example: “A3b,” “j3;M”).
• be a password used in the previous 18 months.
• be similar to your previous password.
• be a palindrome (example: “abc.cba,” “cb,,bc”).
• include the characters ‘ “ ` \
• include character strings from any part of
your name (examples for “James Smith”:
“James,” “ames,” “mith”).
• include part of your name with uppercase
characters (example: “AmeS”).
• include part of your name with numbers
substituted for letters (example: “j4m3s”).
• include reserved strings (example: “wild,” “cats”).
• include part of reserved strings with uppercase
characters (example: “WilD,” “cAtS”).
• include part of reserved strings with numbers
substituted for letters (example: “wi1d,” “E3e3”).
• include repeated letters or numbers
(example: “AaAa,” “3E3e,” “aaaa”).
• include runs of adjacent keys (example: “hjkl”).
November + December 2009
In the absence of standard
guidelines and adequate tools,
different systems implement the
same policies with very different
philosophies and requirements,
complicating life for users who
must use multiple systems.
Developers who lack an understanding of real human behavior
tend to impose logical rules and
requirements upon a bewildered,
overwhelmed audience. The
audience, either not understanding the rationale or simply disagreeing with the necessity for
the procedures imposed upon
them, sees these as impediments
to accomplishing their jobs.
Moreover, the systems people
may lack an understanding of
the clever ruses and social engineering skills of the illegitimate
users, who break into systems
the easy way: by lying, stealing,
and deceiving. The strongest
locks in the world do not deter
the shrewd social engineer.
Only amateurs attack machines;
professionals target people.
Does more security necessarily
translate into less usability? No.
A more secure lock is no more
difficult to operate than a cheap,
insecure one. With appropriate
technology we can make some of
these systems even easier to use
while simultaneously enhancing
security. Biometric identifiers
and radio frequency identification (RFID) tags offer great potential on this front.
Want a classic example of a
failure? Passwords. There are
several myths in the world about
security, but the most pervasive
of these has to do with password
security. Look at Northwestern
University’s password requirements: an overreaction to the
problem of password discovery
through brute-force attacks (see
sidebar above). Breaches can
occur, especially when people
use simple, common passwords
or the names of their family
or pets. There are easy-to-find
lists of common passwords,
and personal information is
readily obtained, sometimes
supplied by the victims themselves on the social sites they
belong to. Systems do need to
be engineered to prevent rapid,
prolonged attempts at finding
passwords, but there is no need
to go to onerous requirements—
just long enough, nonword
combinations that sufficiently
slow up the guessers. Lacking
sophisticated understanding of
the nature of password theft,
system administrators often take
the extreme measures exemplified by Northwestern’s IT department, even though security professionals continuously point out
the harm such schemes produce.
This is another example of
where usability experts can collaborate with security professionals to develop secure yet
Although there is much
emphasis on password security,
most break-ins occur through
other means. Thieves usually
don’t break into systems using
brute force. They phish, luring
unsuspecting but helpful people
to tell them their login name
and password. Or they install
sniffers on keyboards and record
everything that was typed. A
password’s strength is irrelevant
if the thief already possesses it.
Passwords illustrate several
of the difficulties with current
methods of enforcing security.
Passwords are the least expensive mechanism known for
securing systems. But onerous
password requirements reduce
security and increase costs.
They reduce security because
many people either use trivial
algorithms to generate memorable passwords, or write down
their passwords and store them
in easily discoverable places.
They increase costs because
help desks must be staffed to
handle the large number of
users who have forgotten their
passwords and can no longer log
in. These requirements keep out
the good guys without deterring
the bad guys.
Another problem is scale. Most
of us have tens or even hundreds
of passwords. If a single password exceeds the limits of nor-