| Previous | Table of Contents | Next |
Ideas for Improving Reusable Passwords
If you are constrained to relying on reusable passwords for I&A at your site, consider these ideas. Good security practices dictate that each password be subject to an aging rule, such as expiring the password when it becomes 180 days old or after it has been used 265 times. Similar rules should be followed for password composition, requiring that passwords include uppercase, lowercase, numeric, and even some special characters. Another composition recommendation is to limit the number of repeated characters in a password, whether serially repeated or not. To ensure that an attacker must search a large number of alternatives, the password should be the maximum length permitted on the system. Unfortunately, most UNIX systems only support 8-character passwords.
Another password rule is to limit similarities between the user’s previous password and the newly chosen one. You could require that at least six of the characters in the password be different from those used in the previous password. Controlling password history is also a good idea. Some operating systems allow the administrator to configure how many password changes a user must endure before the same password can be reused. To prevent the user from choosing a temporary new password several times until the threshold is reached, a configuration value also is provided for a minimum password age. The user cannot change the password until the minimum age has expired.
The system also can generate passwords for users. Two problems are encountered with this approach. If the password is difficult to guess, the tradeoff is that you will find users writing down the complex strings. On the other hand, if the password generator creates pronounceable strings that fit a particular grammar, an attacker can use this information to narrow the search space. A hacker also can proactively check for passwords as they are chosen by users. Ideas for proactive password checkers can be found in the literature (Stallings, 1995; Bishop, 1993). Logical choices include modifying the change-password routines to invoke programs that compare the user’s choice with dictionary entries.
One additional idea is to require each user to enter more than one password value. That is, authentication would be based on something you know and something you know. Although this method is stronger than a single reusable password, it still suffers from the problems already described. In terms of algorithm complexity, guessing twice as many passwords is negligibly harder for a password cracker.
As you probably have guessed, significantly improving the security of I&A at your site means foregoing reusable passwords. For example, instead of requiring a user to know two passwords for authentication, it would be better to base authenticate on two values selected separately from something you know, something you have, and something you are. Perhaps, you have seen movies in which an employee first inserts a badge into a reader and then also keys an access code into a keypad. Here, authentication is based on something the user has and on something the user knows. Either single authentication item alone is insufficient for gaining access to the target environment.
You will learn about mechanisms that avoid reusable passwords or require multiple authentication values in a few moments. Before doing so, let’s pick up the earlier discussion path and expand your knowledge of authentication servers. Because many improvements to I&A require authentication servers, knowing how a server such as Kerberos works will help you evaluate alternatives. Before reading about Kerberos, you might want to glance through the sidebar, “A Cryptography Primer,” if you are a novice to cryptography. More thorough treatments of cryptography can be found in Schneier (1996), Denning (1983), and Koblitz (1994).
In this section, you learn how authentication servers can be used to solve I&A problems in distributed systems. Specifically, third-party authentication based on Kerberos and X.509 certificates is described.
The goal of a third-party authentication system is to provide secure communications between previously unknown entities. When MIT started the Athena project to deploy a number of distributed systems across a large network, they immediately realized that I&A was the initial weakest link in security. To solve their problems, researchers developed the Kerberos authentication system. Now widely deployed at various sites, Kerberos provides a third-party authentication server across heterogeneous operating systems.
Another third-party system described in this section is based on X.509 digital certificates. One of the drawbacks of Kerberos is that to date it has relied on secret-key technology, or symmetric cryptography, for I&A between entities. Lately, though, extensions have been proposed to Kerberos to support X.509 certificates. The X.509 standard is part of a large body of standards developed by the International Standards Organization (ISO) aimed at solving distributed computing problems. X.509 certificates are based on public key, or asymmetric cryptography, which overcomes some of the critiques of Kerberos mentioned in the following section.
| Previous | Table of Contents | Next |