P1: JDW
WL040C-01 WL040/Bidgoli-Vol III-Ch-01 June 24, 2003 10:39 Char Count= 0
8 PASSWORDSpassword is compromised, all of the user’s accounts will
be compromised. A good social engineering attack might
be to put up an attractive Web site with titillating content,
requiring users to register a username and password in or-
der to access the “free” information. The attacker would
record all passwords (even incorrect ones, which a user
might have mistakenly entered thinking of another ac-
count), and then use those to attack the other systems fre-
quented by the user. The Web site could even solicit infor-
mation from the users about their accounts—for example,
what online brokerage, banking, and e-mail accounts they
used. Web site operators can always keep a log of IP ad-
dresses used to access the site and could go back to attack
the originating system directly.“Dumpster Diving” Attack.Many serious compromises
are still caused by contractors and third parties throwing
away draft instruction manuals, development notes, etc.,
with user IDs and passwords in them. Social engineers
may employ “dumpster diving,” that is, digging through
paper printouts in the trash looking for such significant
information to gain system access.Single Sign-On and Password
Synchronization
One issue that has irritated users in large secure environ-
ments is the burgeoning number of passwords they have
to remember to access various applications. A user might
need one password to log onto his or her workstation, an-
other to access the network, and yet another for a partic-
ular server. Ideally, a user should be able to sign on once,
with a single password, and be able to access all the other
systems on which he or she has authorization.
Some have called this notion of single sign-on the “Holy
Grail” of computer security. The goal is admirable—to
create a common enterprise security infrastructure to re-
place a heterogeneous one. And it is currently being at-
tempted by several vendors through technologies such as
the Open Group’s Distributed Computing Environment
(DCE), MIT’s Kerberos, Microsoft’s ActiveDirectory, and
Public-Key Infrastructure (PKI)-based systems. However,
few, if any, enterprises have actually achieved their goal.
Unfortunately, the task of changing all existing applica-
tions to use a common security infrastructure is very dif-
ficult, and this has further been hampered by a lack of
consensus on a common security infrastructure. As a re-
sult, the disparate proprietary and standards-based solu-
tions cannot be applied to every system. In addition, there
is a risk of a single point of failure. Should one user’s pass-
word be compromised, it is not just his local system that
can be breached but the entire enterprise.
Password synchronization is another means of trying
to help users maintain the passwords that they use to log
onto disparate systems. In this scheme, when users peri-
odically change their passwords, the new password is ap-
plied to every account the user has, rather than just one.
The main objective of password synchronization is to help
users remember a single, strong password. Password syn-
chronization purports to improve security because syn-
chronized passwords are subjected to a strong password
policy, and users who remember their passwords are less
likely to write them down.To mitigate the risk of a single system compromise be-
ing leveraged by an intruder into a network-wide attack:Very insecure systems should not participate in a pass-
word synchronization system,
Synchronized passwords should be changed regularly,
and
Users should be required to select strong (hard to guess)
passwords when synchronization is introduced.Unix/Linux-Specific Password Issues
Traditionally on Unix and Linux platforms, user informa-
tion, including passwords, is kept in a system file called /
etc/passwd. The password for each user is stored as a hash
value. Despite the password being encoded with a one-way
hash function and a salt as described earlier, a password
cracker could still compromise system security if he or she
obtained access to the /etc/passwd file and used a success-
ful dictionary attack. This vulnerability can be mitigated
by simply moving the passwords in the /etc/passwd file
to another file, usually named /etc/shadow, and making
this file readable only by those who have administrator or
“root” access to the system.
In addition, Unix or Linux administrators should ex-
amine the password file (as well as the shadow pass-
word file when applicable) on a regular basis for potential
account-level security problems. In particular, it should
be examined for the following:Accounts without passwords.
UIDs of 0 for accounts other than root (which are also
superuser accounts).
GIDs of 0 for accounts other than root. Generally, users
don’t have group 0 as their primary group.
Other types of invalid or improperly formatted entries.User names and group names in Unix and Linux are
mapped into numeric forms (UIDs and GIDs, respec-
tively). All file ownership and processes use these numer-
ical names for access control and identity determination
throughout the operating system kernel and drivers.
Under many Unix and Linux implementations (via a
shadow package), the commandpwckwill perform some
simple syntax checking on the password file and can
identify some security problems with it.pwckwill re-
port invalid usernames, UIDs and GIDs, null or nonexis-
tent home directories, invalid shells, and entries with the
wrong number of fields (often indicating extra or missing
colons and other typos).Microsoft-Specific Password Issues
Windows uses two password functions—a stronger one
designed for Windows NT, 2000, and XP systems, and a
weaker one, the LAN Manager hash, designed for back-
ward compatibility with older Windows 9X networking
login protocols. The latter is case-insensitive and does
not allow passwords to be much stronger than seven
characters, even though they may be much longer. These
passwords are extremely vulnerable to cracking. On a
standard desktop PC, for example, L0phtCrack can try