How Long Should a Password Be?

It is generally agreed that the eight-character limit that UNIX systems impose is inadequate
[Feldmeier and Karn, 1990; Leong and Tham, 1991]. But how long should a password be?
Part of the problem with the UNIX system’s password-hashing algorithm is that it uses
the seven significant bits of each typed character directly as an encryption key. Since the
algorithm used (DES; see Chapter 13) permits only 56 bit keys, the limit of eight is derived,
not selected. But that begs the question.
The 128 possible combinations of seven bits are not equally probable. Not only do most
people avoid using control characters in their passwords, most do not even use characters
other than letters. Most folks, in fact, tend to pick passwords composed solely of lowercase
letters.
We can characterize the true value of passwords value as keys by using information
theory [Shannon, 1949]. For ordinary English text of 8 letters, the information content is
about 2.3 bits per letter, perhaps less [Shannon, 1948, 1951]. We thus have an effective
key length of about 19 bits, not 56 bits, for passwords composed of English words.
Some people pick names (their own, their spouse’s, their children’s, etc.) for passwords.
That gives even worse results, because of just how common certain names are. Experiments
performed using the AT&T online phone book show that a first name has only about 7.8
bits of information in the whole name. These are very bad choices indeed.
Longer English phrases have a lower information content per letter, on the order of 1.2
to 1.5 bits. Thus, a password of 16 bytes is not as strong as one might guess if words from
English phrases are used; there are only about 219 to 224 bits of information there. The
situation is improved if the user picks independent words, to about 238 bits. But if users
fill up those bytes with combinations of names, we have not helped the situation much.

To enforce password security through retroactive checking [Muffett, 1992]. But perversity always
tends toward a maximum, and the hackers only have to win once.
If you cannot keep people from choosing bad passwords, it is vital that the password file itself
be kept out of enemy hands. This means that one should
􀀀 carefully configure the security features for services such as Sun’s NIS,
􀀀 restrict files available from tftpd, and
􀀀 avoid putting a genuine /etc/passwd file in the anonymous FTP area.
(There is room for fun, of course. Our ftpd will happily deliver /etc/passwd file to you
(Figure 1.2), complete with passwords crackable by trying words from a dictionary [Klein, 1990].
They come to “why are you wasting your time”. The first of these, nominally for root,
has shown up on a hacker bulletin board, which says something about hacker quality control.)
Some UNIX systems provide you with the ability to conceal the hashed passwords from even
legitimate users. If your system has this feature (sometimes called a “shadow” or “adjunct”
password file), we strongly urge you to take advantage of it. Many other operating systems wisely
hash and hide their password files.

Encryption is often touted as the ultimate weapon in the computer security wars. It is not. It is
certainly a valuable tool (see Chapter 13), but it, like everything else, is a tool toward an ultimate
goal. Indeed, if encryption is used improperly, it can hurt the real goals of the organization.
Some aspects of improper use are obvious. One must pick a strong enough cryptosystem for
the situation, or an enemy might cryptanalyze it. Similarly, the key distribution center must be
safeguarded, or all of your secrets will be exposed.
Other dangers exist as well. For one thing, encryption is best used to safeguard file transmission,
rather than file storage, especially if the encryption key is generated from a typed password. Few
people bequeath knowledge of their passwords in their wills; more have been known to walk in
front of trucks. There are schemes to deal with such situations (e.g., [Shamir, 1979; Gifford, 1982;
Blaze, 1994]), but these are rarely used in practice. Admittedly, you may not be concerned with
the contents of your files after your untimely demise, but your organization—in some sense the
real owner of the information you produce at work—might feel differently.
Even without such melodrama, if the machine you use to encrypt and decrypt the files is
not physically secure, a determined enemy can simply replace the cryptographic commands with
variants that squirrel away a copy of the key. Have you checked the integrity of such commands
on your disk recently? Did someone corrupt your integrity-checker?
Finally, the biggest risk of all may be your own memory. Do you remember what password
you used a year ago? (You do change your password regularly, do you not?) You used that
password every day; how often would you use a file encryption key?
If a machine is physically and logically secure enough that you can trust the encryption process,
encryption is most likely not needed. If the machine is not that secure, encryption may not help.
The Ethics of Computer Security 15
There is one exception to our general rule: backup tapes. Such tapes rarely receive sufficient
protection, and there is never any help from the operating system. One can make a very good case
for encrypting the entire tape during the dump process—if there is some key storage mechanism
guaranteed to permit you to read the year-old backup tape when you realize that you are missing a
critical file. It is the information that is valuable; if you have lost the contents of a file, it matters
little if the cause was a hacker, a bad backup tape, a lost password, or an errant rm command.