CSC-STD-002-85 - PASSWORD MANAGEMENTGUIDELINE

	DEPARTMENT OF DEFENSE
	PASSWORD MANAGEMENT
	GUIDELINE

Approved for public release;
distribution limited.

12 April 1985

DEPARTMENT OF DEFENSE

COMPUTER SECURITY CENTER
Fort George G. Meade, Maryland 20755

CSC-STD-002-85

Library No. S-226,994

FOREWORD

This publication, "Department of Defense Password management Guideline," is being issued by the DoD Computer Security Center (DoDCSC) under the authority of and in accordance with DoD Directive 5215.1, "Computer Security Evaluation Center." The guidelines described in this document provide a set of good practices elated to the use of password-based user authentication mechanisms in automatic data processing systems employed for processing classified and other sensitive information. Point of contact concerning this publication is the Office of Standards and Products, Attention: Chief, Computer Security Standards.

Robert L. Brotman 12 April 1985
Director
DoD Computer Security Center

ACKNOWLEDGMENTS

Special recognition is extended to Sheila L. Brand, DoD Computer Security Center (DoDCSC), and Jeffrey D. Makey, formerly DoDCSC, as principal authors of this publication.

Acknowledgment is also given for the contributions of: Daniel J. Edwards, Mary E. Flaherty, Steven J. Padilla, DoDCSC, John J. Stasak III, Gregory L. Wessel and Bernard Peters, Department of Defense, Col. Roger R. Schell, formerly DoDCSC, and James P. Anderson, James P. Anderson & Co, who gave generously of their time and expertise in the formulation and review of this document.

INTRODUCTION

In August 1983, the DoD Computer Security Center published CSC-STD-001-83, Department of Defense Trusted Computer System Evaluation Criteria. That publication defines and describes feature and assurance requirements for six hierarchical classes of enhanced security protection for computer systems that are to be used for processing classified or other sensitive information. A major requirement common to all six classes is accountability:

"Individual accountability is the key to securing and controlling any system that processes information on behalf of individuals or groups of individuals. A number of requirements must be met in order to satisfy this objective.

"The first requirement is for individual user identification. Second, there is a need for authentication. Without authentication, user identification has no credibility. Without a credible identity (no) security policies can be properly invoked because there is no assurance that proper authorizations can be made." (2)

This guideline has been developed `to assist in providing that much needed credibility of user identity by presenting a set of good practices related to the design, implementation and use of password-based user authentication mechanisms. It is intended that features and practices described in this guideline be incorporated into DoD automatic data processing (ADP) systems used for processing classified or other sensitive information.

1.0 SCOPE

The security provided by a password system depends on the passwords being kept secret at all times. Thus, a password is vulnerable to compromise whenever it is used, stored, or even known. In a password-based authentication mechanism implemented on an ADP system, passwords are vulnerable to compromise due to five essential aspects of the password system:

1) a password must be initially assigned to a user when enrolled on the ADP system;
2) a user's password must be changed periodically;
3) the ADP system must maintain a "password database";
4) users must remember their passwords; and
5) users must enter their passwords into the ADP system' at authentication time.

This guideline prescribes steps to be taken to minimize the vulnerability of passwords in each of these circumstances.

Specific areas addressed in this guideline include the responsibilities of the system security officer and of users, the functionality of the authentication mechanism, and password generation. The major features advocated in this guideline are:

Users should be able to change their own passwords.

Passwords should be machine-generated rather than user-created.

Certain audit reports (e.g., date and time of last login) should be provided by the system directly to the user.

For certain sensitive applications such as Command and Control Systems, pertinent DoD directives should be referenced in order to assess the need for additional identification and authentication features.

2.0 CONTROL OBJECTIVES

The CSC-STD-001-83 gives the following as the Accountability Control Objective:

"Systems that are used to process or handle classified or other sensitive information must assure individual accountability whenever either a mandatory or discretionary security policy is invoked. Furthermore, to assure accountability, the capability must exist for an authorized and competent agent to access and evaluate accountability information by a secure means, within a reasonable amount of time, and without undue difficulty."(2)

In order to attain the individual accountability required, it is necessary for the ADP system to be able to uniquely identify each person who uses it. In many cases, a password scheme will be used to achieve this. The Accountability Control Objective, applied to password systems, leads to the following control objectives for password systems.

Personal Identification

Password systems used to control access to ADP systems that process or handle classified or other sensitive information must assure the capability to uniquely identify each individual user of the system.

Authentication

Password systems used to control access to ADP systems that process or handle classified or other sensitive information must assure unequivocal authentication of the user's claimed identity.

Password Privacy

Password systems must assure, to the extent possible, protection of the password database consistent with protection afforded the classified or other sensitive information processed or handled by the ADP system in which the password systems operate.

Auditing

Password systems used to control access to ADP systems that process or handle classified or other sensitive information must be able to assist in the detection of password compromise.

3.0 DEFINITIONS

Access Port - A logical or physical identifier that a computer uses to distinguish different terminal input/output data streams.

Expired Password - A password that must be changed by the user before login may be completed.

Password - A character string used to authenticate an identity. Knowledge of the password that is associated with a user ID is considered proof of authorization to use the capabilities associated with that user ID.

Password System - A part of an ADP system that is used to authenticate a user's identity. Assurance of unequivocal identification is based on the user's ability to enter a private password that no one else should know.

System Security Officer (SSO) - The person responsible for the security of an ADP system. The SSO is authorized to act in the "security administrator" role defined in CSC-STD-001-83. Functions that the SSO is expected to perform include: auditing and changing security characteristics of a user.

Trusted Identification Forwarding - An identification method used in networks where the sending host can verify that an authorized user on its system is attempting a connection to another host. The sending host transmits the required user authentication information to the receiving host. The receiving host can then verify that the user is validated for access to its system. This operation may be transparent to the user.

User ID - A unique symbol or character string that is used by an ADP system to uniquely identify a user. The security provided by a password system should not rely on secrecy of the user's ID.

4.0 GUIDELINES

In the remainder of this document, guidelines for good practice are presented in bold print, while amplifications, examples, and rationale are presented in normal print. The guidelines are given with two degrees of emphasis. Those that are most important to the security of a password system are presented with such wording as "The SSO should ..." (the word "should" is the key), while less critical functions are presented with such wording as "It is recommended that." ("recommended" is the key). Because it is anticipated that diverse user communities will adopt this guideline, all recommendations are presented in general rather than specific terminology, divorced from vendor-specific hardware or system software. Where features require the setting of a specific value (e.g., password maximum lifetime), it is suggested that these be designed as parametric settings leaving the determination of exact values to local security management who understand the particular security requirements of their user environment.

It is recommended that, whenever possible, the mechanisms discussed in this guide be automated. Automation will result in a minimal burden on the system administration and on the users, and thus in greater effectiveness of the mechanisms by eliminating situations where passwords might be exposed to people.

4.1 SSO Responsibilities

4.1.1 Initial System Passwords

Many ADP systems come from the vendor with a few standard user IDs (e.g., SYSTEM, TEST, MASTER, etc.) already enrolled in the system. The System Security Officer (SSO) should change the passwords for all standard user IDs before allowing the general user population to access the system. This can be easily assured if the standard user IDs are initially identified by the system as having "expired" passwords. (See section 4.2.2.1 for discussion of expired passwords.)

4.1.2 Initial Password Assignment

The SSO is responsible for generating and assigning the initial password for each user ID. The user must then be informed of this password. In some areas, it may be necessary to prevent exposure of the password to the SSO. In other cases, the user can easily nullify this exposure.

4.1.2.1 Preventing Exposure

There are methods that can be implemented to prevent exposure of a password to the SSO after it has been generated. One technique is to print the user's password on a sealed multipart form in such a way that it is not visible on the top page of the form. The SSO would then protect the sealed password appropriately until it could be delivered to the user. In this case, the password is generated randomly by the ADP system and is not known by the SSO.

The password should be seated so it is not visible and cannot be made visible without breaking the seal. Delivery of the password in this manner could require several days.

Another method of preventing exposure is to have the user present at password generation. The SSO must initiate the procedure and the user must shield the generated password and then remove or erase it from the display. This method cannot be used when user terminals are at remote locations.

It is recommended that a technique comparable to one of the above be used to prevent exposing a user's initial password to the SSO. Whatever method is used to distribute passwords, the SSO must receive an acknowledgment of receipt of the password within a specified time period.

4.1.2.2 Nullifying Exposure

When a user's initial password must be exposed to the SSO, this exposure may be nullified by having the user immediately change the password by the normal procedure. (Presumably, this change procedure does not expose the new password to the SSO.)

When a user's initial password is not protected from exposure to the SSO, the user ID should be identified by the system as having an "expired password" which will require the user to change the password by the usual procedure (see section 4.2.2.3) before receiving authorization to access the system.

4.1.2.3 Classification Assignment

Where the password must be classified, the initial classification assignment should be entered by the SSO to designate the highest security level that may be associated with each user's initial password and its successors.

4 1.3 Password Change Authorization

Occasionally, a user will forget the password or the SSO may determine that a user s password may have been compromised. To be able to correct these problems, it is recommended that the SSO be permitted to change the password of any user by generating a new one. The SSO should not have to know the user's password in order to do this, but should follow the same rules for distributing the new password that apply to initial password assignment (see section 4.1.2). Positive identification of the user by the SSO is required when a forgotten password must be replaced.

4.1.4 Group IDs

Throughout the lifetime of an ADP system, each user ID should be assigned to only one person. In other words, no two people may ever have the same user ID at the same time, or even at different times. It should be considered a security violation when two or more people know the password for a user ID (except in the case when the SSO is the other person and the user ID is identified by the system as having an "expired password">. Note that there is no intention of prohibiting alternate forms of user identification (e.g., group IDs,functional titles) for non-authentication purposes (e.g., data access control, mail). If alternate IDs are used, they must be based on user IDs.

4.1.5 User ID Revalidation

The SSO should be responsible for the development of a procedure whereby prompt notification is given to the SSO when a user ID and password must be removed from the ADP system (e.g., when an employee leaves the sponsoring organization). In addition, all user IDs should be revalidated periodically, and information such as sponsor and means of off-line contact (e.g., phone number,mailing address) updated as necessary. It is recommended that this revalidation be done at least once per year.

4.2 User Responsibilities

4.2.1 Security Awareness

Users should understand their responsibility to keep passwords private and to report changes in their user status, suspected security violations, etc. To assure security awareness among the user population, it is recommended that each user be required to sign a statement to acknowledge understanding these responsibilities.

4.2.2 Changing Passwords

The simplest way to recover from the compromise of a password is to change it. Therefore, passwords should be changed on a periodic basis to counter the possibility of undetected password compromise. They should be changed often enough so that there is an acceptably low probability of compromise during a password's lifetime. To avoid needless exposure of users' passwords to the SSO, users should be able to change their passwords without intervention by the SSO.

4.2.2.1 Password Lifetime

The most obvious threat to the security provided by a password system is from the compromise of passwords. The greater the length of time during which a password is used for authentication purposes,the more opportunities there are for exposing it. In a useful password system, the probability of compromise of a password increases during its lifetime. For a period of time, this probability could be considered acceptably low while after a longer period of time, it would be considered unacceptably high. At this latter point, use of the password should be considered suspect rather than a reliable proof of identity. By appropriately limiting the length of time (called the password lifetime) during which a password can be used,the vulnerability of the password can remain acceptable. There should be a maximum lifetime for all passwords. To protect against unknown threats, it is recommended that the maximum lifetime of a password be no greater than 1 year. The presence of known threats may indicate a need for a shorter maximum lifetime. Also, depending on the size of the password space and on how fast a penetrator can execute a login attempt, it may be necessary to change passwords even more frequently. See Appendix C for a discussion of the relationship between password lifetime, password space and the guess rate. A password should be invalidated at the end of its maximum lifetime. It is recommended that, at a predetermined period of time prior to the expiration of a password's lifetime, the user ID it is associated with be notified by the system as having an "expired" password. A user who logs in with an ID having an expired password should be required to change the password for that user ID before further access to the system is permitted. If a password is not changed before the end of its maximum lifetime, it is recommended that the user ID it is associated with be identified by the system as "locked." No login should be permitted to a locked user ID, but the SSO should be able to unlock the user ID by changing the password for that user ID, following the same rules that apply to initial password entry (see section 4.1.2). After a password has been changed, the lifetime period for the password should be reset to the maximum value established by the system.

4.2.2.2 Change Authorization

To be consistent with the Password Privacy control objective, users (other than the SSO) should be permitted to change only their own passwords. To ensure this, it is recommended that the user enter the old password and the user ID/password combination be validated as part of the password changing procedure.

4.2.2.3 Change Procedure

Changing a password in a secure manner involves several steps. The following procedure is recommended:

The procedure should be invoked at the user's request or when a user logs in with an expired password. If the change is necessary due to an expired password, the user should be so informed. The user should be presented with a brief summary of the major steps in changing a password, including a caution that the user should ensure that no one else is watching what the user is doing. Except when the change procedure is part of the login procedure (e.g., logging in with an expired password), the user's current password should be entered to re-authenticate identity. The change procedure should display a new password for the user. The new password should be different from the old one and should be generated by any algorithm that satisfies the specifications in Appendix A. The user should then enter the new password twice so the procedure can verify that the user can consistently enter the password correctly. The new password should be obliterated by techniques such as overprinting or terminal screen erasing. If the two entered passwords are identical to the generated password, the password data base should be updated (i.e., the old password deleted or invalidated andthe new password associated with the user ID) and a message to this effect should be displayed. Failure by the user to correctly enter the current password or the generated password should result in a useful error message to the user and in the change procedure being aborted without changing the password. When the attempt to change an expired password is not successful, the password should be retained as expired and the user given the option to again change the password or logout. An audit record should be generated that indicates whether or not the change was successful.

4.2.3 Login to a Connected System

Users should be required to authenticate their identities at "login" time by supplying their password along with their user ID. It is recommended that some form of trusted identification forwarding be used between hosts when users connect to other ADP systems through a network. When trusted identification forwarding is not used, a remote host should require the user's ID and password when logging in through a network connection. Note that user IDs on different hosts for the same user may be different, and that corresponding machine-generated passwords almost certainly will be different. Note also that a password required by a remote host is vulnerable to compromise by the local host or intermediate hosts.

4.2.4 Remembering Passwords

Since users must supply their passwords to the ADP system at authentication time, it follows that they must know what their passwords are. It is recommended that users memorize their passwords and not write them on any medium. If passwords must be written,they should be protected in a manner that is consistent with the damage that could be caused by their compromise. See Appendix D for guidance on the protection of passwords.

4.3 Authentication Mechanism Functionality

4.3.1 Internal Storage of Passwords

It is normally necessary for the ADP system to store internally the user ID for each authorized system user as well as some representation of the password and, when required, the clearance and authorizations that are associated with each user ID. Without some form of access control over this information, it will be possible for unauthorized users to read and/or modify the password database. Unauthorized reading and writing of the password database are a concern. Reading it could result in disclosure of passwords to unauthorized users. Being able to write it could result, for example, in user A changing user B's password so user A could log in under user B's identity. Note that it is necessary for the login process to be able to read the password database and the password changing process to be able to read and write the password database.

Stored passwords should be protected by access controls provided by the ADP system, by password encryption, or by both.

4.3.1.1 Use of Access Control Mechanisms

Access control mechanisms (e.g., mandatory or discretionary controls as discussed in CSC-STD-001-83) should be used to protect the password data base from unauthorized modification and disclosure.

4.3.1.2 Use of Encryption

4.3.2 Entry

Encryption of stored passwords should be used whenever the access control mechanisms provided by the ADP system are not adequate to prevent exposure of the stored passwords. It is recommended that password encryption be used even when other access controls are considered adequate, as this helps protect against possible exposure when access controls are bypassed (e.g., system dumps). When encryption is used to protect stored passwords, it is recommended that the algorithm meet the specifications in Appendix B. It is recommended that encryption be done immediately after entry, that the memory containing the plaintext password be erased immediately after encryption, and that only the encrypted password be used in comparisons. There is no need to be able to decrypt passwords. Comparisons can be made by encrypting the password entered at login and comparing the encrypted form with the encrypted password stored in the password database. Passwords should be entered after providing a user ID to the system. If the entry is correct, the system should then display the date and time of the user's last login. It is recommended that the system not echo passwords that users type in. When the system cannot prevent a password from being echoed (e.g., in a half-duplex connection), it is recommended that a random overprint mask be printed before or after the password is entered, as appropriate, to conceal the typed password. The complete password as entered by the user should be an exact match, character for character, with the user's current password.

4.3.3 Transmission

During transmission of a password from a user's terminal to the computer in which the authentication is done, passwords should be protected in a manner that is consistent with the damage that could be caused by their compromise. Since passwords are no more sensitive than the data they provide access to, there is generally no reason to protect them, during transmission, to any greater degree (e.g.,encryption) than regular data is protected. See Appendix D for guidanceon the protection of passwords.

4.3.4 Login Attempt Rate

By controlling the rate at which login attempts can be made (where each attempt constitutes a guess of a password), the number of guesses a penetrator can make during a password's lifetime is limited to a known upper bound. To control attacks where a penetrator attempts many logins through a single access port, the password guess rate should be controlled on a per-access port basis. That is, each access port should be individually controlled to limit the rate at which login attempts can be made at each port. When a penetrator can easily switch among multiple access ports, it is recommended that the password guess rate also be controlled on a per-user ID basis. It is recommended that maximum login attempt rates fall within the range of one per second to one per minute. This range provides reasonable user-friendliness without permitting so many login attempts that an extremely large password space or an extremely short password lifetime is necessary. See Appendix C for a discussion of the relationship between the guess rate, password lifetime, and password space. Note that it is not intended that login be an inherently slow procedure, for there is no reason to delay a successful login. However, in the event of an unsuccessful login attempt, it is quite reasonable to use an internal timer to enforce the desired delay before permitting the next login attempt. The user should not be able to bypass this procedure.

4.3.5 Auditing

4.3.5.1 Audit Trails

The system should be able to create an audit trail of password usage and changes. Such an audit trail should not contain actual passwords or character strings that were incorrectly given as passwords, since this could expose the password of a legitimate user who mistyped his user ID or password.

Auditable events should include: successful login, unsuccessful login attempts, use of the password changing procedure, and the locking of a user ID due to its password reaching the end of its lifetime. For each recorded event, the audit record should include: date and time of the event, type of event, offered user ID for unsuccessful logins or actual user ID for other events, and origin of the event (e.g., terminal or access port). Audit records of password changes should also indicate whether or not the change was successful.

4.3.5.2 Real-time Notification to System Personnel

It is recommended that each accumulation of 5 consecutive unsuccessful login attempts from a single access port or against a single user ID results in immediate notification of the event to the ADP system operator or the SSO. While there is no requirement for the SSO or operator to take any action upon receiving the notification, frequent notifications may indicate that a penetration attempt is in progress and may warrant investigation and possible corrective action.

4.3.5.3 Notification to the User

Upon successful login, the user should be notified of:

The date and time of user's last login;

The location of the user (as can best be determined) at last login; and

Each unsuccessful login attempt to this user ID since the last successful login.

This provides a means for the user to determine if someone else is using or attempting to guess this user ID and password.

4.4 Password Protection

4.4.1 Single Guess Probability@

The probability that any single attempt at guessing a password will be successful is one of the most critical factors in a password system. This probability depends on the size of the password space and the statistical distribution within that space of passwords that are actually used. Since many user-created passwords are particularly easy to guess all passwords should be machine generated using an algorithm that meets the specifications in Appendix A.

4.4.2 Password Distribution

During distribution to the user, passwords should be protected to the same degree as the information to which they provide access. Machine-generated passwords should be displayed on the user's terminal at time of change, along with appropriate cautions to the user to protect the password. At the completion of the change procedure, it is recommended that displayed passwords be erased or overstruck, as appropriate for the terminal type. Passwords changed by the SSO should be distributed in a manner that is consistent with the damage that could be caused by their compromise. See Appendix D for guidance on the protection of passwords.

APPENDIX A

Password Generation Algorithm

This appendix describes the requirements to be met by an acceptable password generation algorithm. The issues involved relate to the specifications for password space, random seed generation, pseudo-random number generation and "user- friendly" passwords.

A.1 Password Space

The size of the password space is a function of the size of the alphabet and the number of characters from that alphabet that are used to create passwords. (The maximum size of the password space can be expressed as S=AM where S is the maximum password space, A is the alphabet size and M is the password length.)

To determine the minimum size of the password space needed to satisfy the security requirements for an operational environment, equation [3] in Appendix C can be used. The password generation algorithm selected should be able to generate at least that number of passwords. In addition, the generated passwords should be, at a minimum, 6 characters in length.

A.2 Random Seeds

When a pseudo-random number generator is used in a password generation algorithm, it should accept as input random data that would provide output which has a high degree of unpredictability. This random data (seed) can be derived from a number of available parameters such as a system clock, system registers, date, time, etc. The parameters should be selected to ensure that the number of unique seeds that can be generated from these inputs should be at least equal to the minimum number of passwords that must be generated. When passwords are used to protect classified information, the seed generator should be approved by the DoD Computer Security Center.

A.3 Pseudo-Random Number Generator

Using a random seed as input, the pseudo-random number generator that drives a password generation algorithm should have the property that each bit in the pseudo-random number that it generates is a complex function of all the bits in the seed. The Federal Data Encryption Standard (DES), as specified in FIPS 46, (9) is an example of a pseudo-random number generator with this property. If DES is used, it is suggested that the 64-bit Output Feedback (OFB) mode be used as specified in FIPS 81 (10). In this case, the seed used as input could consist of:

An initialization vector
A cryptographic key
Plaintext

Factors that can be used as input to these parameters are:

For the initialization vector:

System clock
System ID
User ID
Date and time

For the cryptographic key:

System interrupt registers
System status registers
System counters

The plain text can be an external randomly generated 64-bit value (8 characters input by the SSO).

The resulting pseudo-random number that is output will be the 64 bits of cipher text generated in the 64-bit OFB mode. The password generation algorithm can either format this pseudo-random number into a password or use it as an index (or indices) into a table and use the contents from this table to form a password or a passphrase.

A.4 "User-Friendly" Passwords

To assist users in remembering their passwords, the password generation algorithm should generate passwords or passphrases that are "easy" to remember. Passwords formed by randomly choosing characters are generally difficult to remember. Passwords that are pronounceable are often easy to remember, as are passphrases that are formed by concatenating real words into a phrase or sentence.

APPENDIX B

Password Encryption Algorithm

Password encryption is advocated as a password protection measure. The algorithm selected for this would be determined by the system environment. Some environments may require that a classified encryption algorithm be used, while for other environments an unclassified algorithm would be required.

B.1 Encryption Algorithm

A conventional or public key cryptographic algorithm which is configured as a "one-way" encryption algorithm may be used for password encryption, but whatever algorithm is used, the protection the encryption algorithm provides should rely on its complexity. If there is a key that can be used with the algorithm to decrypt passwords, that key should not be stored in the ADP system.

B.2 Assurance for Unique Encrypted Passwords

If a password encryption system depends only on the password and other fixed information, there is a possibility that two different users will have identical encrypted passwords. A user who discovers another user with an identical encrypted password will then know that the same password will work for both user IDs even if they don't have identical plaintext passwords. To minimize this possibility, it is recommended that the encryption algorithm use the ADP system name (in network environments) and the user's ID as factors in the encryption. (This can be easily accomplished by concatenating the system ID, user ID and password, and then applying the encryption algorithm to the resulting string.)

APPENDIX C

Determining Password Length

The security afforded by passwords is determined by the probability that a password can be guessed during its lifetime. The smaller that probability, the greater the security provided by the password. All else being equal, the longer the password, the greater the security it provides. This appendix reviews the mathematics involved in establishing how long a password should be.

The basic parameters that affect the length of the password needed to provide a given degree of security are:

L = maximum lifetime that a password can be used to log into the system.

P = probability that a password can be guessed within its lifetime, assuming ontinuous guesses for this period.

R = number of guesses per unit of time that it is possible to make.

S = password space, i.e., the total number of unique passwords that the assword generation algorithm can generate.

C.1 Relationship

Considering only the cases where S is greater than L x R and therefore P is less than 1, the relationship between these parameters is expressed by the equation:

P = L x R

A detailed explanation of the derivation of this basic equation is given in Appendix F.

C.2 Guess Rate

Several factors contribute to the rate at which attempts can be made to gain access to the data on a system when a valid password is not known. First and foremost is the protection given to the password data base itself. If the password data base is unprotected (i.e., can be read by anyone as ordinary data), then "guessing" may not be required.

If the password data base can be read,but the passwords are encrypted (see Appendix B), a very high guess rate may be possible by using a computer to try a dictionary of possible passwords to see if ciphertext can be generated that is the same as one in the password data base. A similar situation frequently occurs where only passwords are used to protect files.

Finally, if the password data base has effective access controls and the login procedure cannot be bypassed, the guess rate can be controlled by setting limits on the number of login or other attempts that can be made before terminating the connection or process.

C.3 Password Lifetime

All other things being equal, the shorter the lifetime of a password, the fewer the number of guesses that can be made and thus the greater the degree of password security. As stated in 4.2.2.1, the maximum password lifetime should not exceed one year.

C.4 Password Space

Password length and alphabet size are factors in computing the maximum password space requirements. Equation [2] expresses the relationship between S, A, and M where:

S = password space
A = number of alphabet symbols
M = password length

S = AM

To illustrate: If passwords consisting of 4 digits using an alphabet of 10 digits (e.g., 0-9) are to be generated:

S = 104

That is, 10,000 unique 4-digit passwords could be generated. Likewise, to generate random 6-character passwords from an alphabet of 26 characters (e.g., A-Z)

S = 266

That is 3.089 * 108 unique 6-character passwords could be generated.

"User-friendly" passwords (sometimes referred to as passphrases) could be generated by using, for example, 3 symbols from an alphabet (dictionary) of 2000 symbols, where each symbol was a pronounceable word of 4, 5, or 6 characters.

Using equation [2] and setting:

A = 2000 symbols (words)

M = 3
Then S = 20003

That is, 8 * 109 unique passwords could be generated where each password was made up of 3 words taken from a dictionary of 2000 words.

C.5 A Procedure for Determining Password Length

What is important in using passwords is how long to make the password to resist exhaustive penetration attacks. We can do this by using the following procedure:

a. Establish an acceptable probability, P, that a password will be guessed during its lifetime. For example, when used as a login authenticator, the probability may be no more than 1 in 1,000,000. In another case, where very sensitive data is involved, the value for P may be set at 10-20.

b. Solve for the size of the password space, S, with the equation derived from equation [1]

S = G

P
where G = L x R

c. Determine the length of the password, M, from the equation

M = log S
log (number of symbols in the "alphabet")

M will generally be a real number that must be rounded up or down to the nearest whole number. Examples of calculating many of the values described above are given below.

C.6 Worked Examples

An example shown here is drawn from a real network case. The problem is to determine the needed password length to reduce to an acceptable level the probability that a password will be guessed during its lifetime.

The network to which this is applied supports both a 300-baud and a 1200-baud service. Experiments on the network have determined that it is possible to make about 8.5 guesses per minute on the 300-baud service and 14, guesses per minute on the 1200-baud service. (The reason that the "guess rate' for the 1200-baud service is not 4 times that of the 300-baud service is that the system response time, which is not affected by the improved transmission speed, becomes the limiting factor in how many guesses can be accomplished in a given amount of time.)

In this example, the arbitrary value of 10-6 is used for the probability (P) of guessing the password in its lifetime. As we will see below, the password lifetime is not the critical factor here as long as the password is changed at least once per year.

The statement of the problem is to find a password length that will resist being guessed with a probability of 1 in 106 in 1 year of continuous guesses.

When three parameters in equation [1] are known, the fourth value can be found. To find the password space required by our examples, the following parameters are given:

L is set for 6 months and 12 months.

P is set for 1 in 1,000,000 (acceptable probability of guessing the password).

R is set at 8.5 guesses per minute (guess rate possible with 300-baud service).

At 8.5 guesses per minute, the number of guesses per day would be 12,240.

Substituting 183 days for 6 months then using equation [3],

S = G = 183x12240 = 2.23992x1012 passwords

P .000001

The 12-month value is twice that of the 6-month case.

With this data, and using equation [4], we can determine the length of the passwords as a function of the size of the alphabet from which they are drawn. We will assume two alphabet sizes: a 26-letter alphabet and a 36-letter-and-number alphabet.

M = log (2.23992 x 1012) = 8.72 (for 6-month lifetime)
log 26

M = log (4.4676x1012) = 8.94 (for 12-month lifetime)

log 26

M = log (2.23992x1012) = 7.93 (for 6-month lifetime)
log 36

M = log (4.4676 x 1012) = 8.13 (for 12-month lifetime)
log 36

Table 1 presents the results.

TABLE 1

MAXIMUM LIFETIME         Length of Password        Length of Password       
(months)                                                                    

                         26-Character alphabet     36-Character alphabet    

6                        9 (rounded up from 8-72)  8 (rounded up from       
                                                   7.93)                    

12                       9 (rounded up from 8.94)  8 (rounded down from     
                                                   8.13)

C.7 Passphrases

A "passphrase" is a concatenation of words drawn from a dictionary. The dictionary is merely the collection of symbols making up the "alphabet" from which the password is generated. As an example, suppose the passphrase is made up of words drawn from a dictionary of 4, 5 and 6 letter words. There are approximately 3,780 4-letter words, 7,500 5-letter words and 12,000 6-letter words in English. The "alphabet size" for generating passphrases is approximately 23,300. We can compute how many words, drawn at random from the dictionary of 23,300 words, are needed to produce a passphrase that will be resistant to exhaustive attack with the probability of 1 x 10-6.

We have to solve for S as before, and from that, solve for M, the length of the password (i.e., number of alphabet symbols or words).

For L = 12 months, S = 4.4676 * 1012, log S = 12.6500

For L = 6 months, S = 2.2399 * 1012, log S = 12.3502

Log 23300 = 4.3669

Using equation (4) we obtain:

For L = 12 months M = 12.6500 = 3 (rounded from 2.89)
4.3669

For L = 6 months M = 12.3502 = 3 (rounded from 2.82)
4.3669

Thus, for the passphrase algorithm described, namely selection at random from a dictionary of 23,300 words, only 3 words are needed in a passphrase to obtain the desired resistance to exhaustive enumeration. In using the algorithm, each word of the phrase is drawn independently from the dictionary. This may result in a word appearing more than once in the passphrase.

APPENDIX D

Protection Basis for Passwords

Passwords are used to prevent people who have physical access to an ADP system from gaining access to data belonging to another user. Thus, a password should be protected in a manner that is consistent with the damage that might be caused by its exposure to someone who has the opportunity to use it (i.e., has physical access to the ADP system terminals). Exposure of a password to someone who is physically prevented from attempting to use it is not a threat.

D.1 Systems Containing Only Unclassified Information

Although an ADP system may process only unclassified information, it still may require that the data be protected from unauthorized use. Although the password is unclassified, the obligation remains that the user protect this password so that only those with a need-to-know can access the data.

D.2 Systems Containing Classified Information

Passwords that are used in ADP systems that operate in the dedicated or system high security modes (3) should not be classified, but should be protected to the same degree as [sensitive but unclassified]. In this case, there is no need to classify passwords since access to the area in which the system resides is restricted to those with a clearance as high as the highest classification level of the information processed. A person who obtained a password for a system running in dedicated or system high security mode but who did not possess the proper security clearance would be unable to gain physical access to the system and use the password.

For systems operating in the multilevel security mode (3), passwords may or may not have to be classified.

When the ability to access classified information is based on the physical protection of the terminal rather than on the identity of the user (i.e., when all terminals are single-level devices), passwords should not be classified, but should be protected to the same degree as For Official Use Only information. There is no need to classify passwords that can only be used on single-level terminals, since physical access to single-level terminals is controlled to the level associated with the terminal. When the ability to access classified information is based on the user's identity and is not restricted by the level of the terminal (i.e., multilevel terminals), each password must be classified to the highest level of the information to which it provides access. When multilevel terminals are used, the system determines the user's access authorizations to classified material based on his identity, and authenticates the identity by requiring a password. Thus. the ADP system can protect the information it processes only to the extent that passwords are protected. For example, a user with a Secret clearance can access Secret information.

Compromise of that user's password could result in the compromise of Secret information; therefore, the password would be classified Secret. In the case of a system with multilevel terminals, disclosure of a Top Secret user's password to a Secret user would allow the Secret user to login as the Top Secret user and thus gain access to Top Secret information. Disclosure of Top Secret information to someone with only a Secret clearance can cause exceptionally grave damage to the national security. Since disclosure of the Top Secret user's password could lead to this, the password must be classified Top Secret (5).

Note that classified passwords must not be used on terminals that are not authorized for data at the level of the password (e.g., a Top Secret password must not be used on a Secret terminal). The presence of both single-level and multilevel terminals on a system may indicate the need for passwords at each security level. At a minimum, an unclassified password should be available for use on terminals that are only authorized for unclassified data.

APPENDIX E

Features for Use in Very Sensitive Applications

The following features can be used to enhance the security provided by a password system. Because they are somewhat "user-unfriendly," they are recommended for environments only when there is a high threat of password compromise.

E.1 One-Time Passwords

One-time passwords (i.e., those that are changed after each use) are useful when the password is not adequately protected from compromise during login (e.g., the communication line is suspected of being tapped). The difficult part of using one-time passwords is in the distribution of the new passwords. If a one-time password is changed often because of frequent use, the distribution of new one-time passwords becomes a significant point of vulnerability. There are products on the market that generate such passwords through a cryptographic protocol between the destination host and a hand-held device the user can carry.

E.2 Failed Login Attempt Limits

In some instances, it may be desirable to count the number of unsuccessful login attempts for each user ID and to base password expiration and user ID locking on the actual number of failed attempts. (Changing a password would reset the count for that user ID to zero.) For example, the password could be identified as expired after 100 failed login attempts, and the user ID locked after 500.

APPENDIX F

On the Probability of Guessing a Password

Appendix C discusses the techniques for finding a password length that will resist exhaustive enumeration over the lifetime of the password with a given probability. This appendix derives the probability of guessing a password during its lifetime. As in Appendix C, we use the parameters:

L = password lifetime
R = guess rate
S = size of the password space
P = probability of guessing a password during its lifetime

The total number of guesses, (G), that can be made during a password's lifetime is:

G = R x L [1]

At this point, we need to consider the relation of the size of the password space, 5, to G. Clearly, if 5 is so small that one could try all possible passwords before the lifetime of the password expires, the probability of guessing the password is l. As a result, we consider only cases where 5 is greater than G.

The probability question then is, "For the case where 5 is greater than G, what is the probability that in G guesses the password will be guessed?" This is the same as asking the question, "What is the probability that in the lifetime of the password, it will be guessed?" The probability sought is:

How many ways one can make G guesses (of S objects)

P = that include the password

How many different ways one can make G guesses of S objects

Note that the probability that is appealed to is of the simplest form. It is derived from the definition of probability that the probability of an event is given by the number of ways the event can happen divided by the number of ways an event can happen or fail.

We first observe that the total number of ways one can make G guesses of S things is given by sCg (the combinatorial notation that means the number of combinations of "s" things taken "g" at a time). (Lower case letters are used with the combinatorial notation in order to make the expressions more readable.) This is determined by:

g!(s-g)!

Thus, if S = A B C,D,E, one could make 3 guesses in 5C3 different ways, 5*4*3*2*1/3*2*1*2*1 = 10.

(Enumerating, they are ABC,ABD,ABE,ACD,ACE,ADE,BCD,BCE,BDE,CDE.)

The problem of finding the number of guesses of this total that include a specific password, e.g., an "A", is addressed by considering a reduced set without the specific password and asking how many ways one can make G guesses with the reduced set. Then, the total number of ways to make G guesses that include the specified password is the difference between the two values. This is given by:

sCg - (s-1)Cg [2]

That is, remove the designated password from the set S, compute the number of ways of making G guesses without the password, then consider the difference between the two values.

If we ask in our example how many ways to make 3 guesses that do NOT include a particular password from the set of 5 (say an "A"), this is given by:

4C3 = 4*3*2*1/3*2*1*1 = 4

Enumerating for the specific case of an "A", they are BCD,BCE,BDE,CDE.

The number of ways to make 3 guesses that include the designated element is 10-4 = 6. Thus, the probability of guessing a designated password in 3 guesses is 6/10 or .6.

Simplification:

It is indeed fortuitous that there is a theorem in any number of books on Probability Theory that states:

nCr = (n-1)C(r-1) + (n-1)Cr [3]

This may also be expressed as:

nCr- (n-1)Cr = (n-1)C(r-1) [4]

Substituting s for n and g for r we obtain the expression:

(s-1)C(g-1) [5]

for the number of ways of making G guesses that include a specific password. Then, the probability that a given password will be guessed during the lifetime of that password is given by:

P = (s-1)C(g-1) [6]

sCg

Evaluating this expression gives:

(s-1)! (s-1)!

P = (g-1)!((s-1)-(g-1))! = (g-1)!(s-g)! = g!(s-1)! = g [7]

s! s! (g-1)!s! s

g!(s-g)! g!(s-g)!

This derivation of the probability of guessing a password during its lifetime, i.e.,

P = G [8]

S

is important in that it allows us to derive the size of the password space

S = G [9]
P
given an acceptable probability of not guessing the password during its lifetime.

REFERENCES

	1. Brown, R. L. Computer System Access Control Using Passwords, 1985 , Aerospace Corporation, 16 January 1984.
	2. DoD Computer Security Center. Department of Defense Trusted Computer System Evaluation Criteria, CSC-STD-00183, 15 August 1983.
	3. DoD Directive 5200.28, Security Requirements for Automatic Data Processing (ADP) Systems, revised April 1978.
	4. Downey, P. J. Multics Security Evaluation: Password and File Encryption Techniques, ESD-TR-74-193, Vol. III, AD-A045279, AFSC Electronic Systems Division, Hanscom AFB, Mass., June 1977.
	5. Executive Order 12356, National Security Information, 6 April 1982.
	6. Gasser, M. A Random Word Generator for Pronounceable Passwords, MTR-3006, ESD-TR-75-97, AD-A017676, MITRE Corp., Bedford, Mass.,November 1975.
	7. Wood, H.M. The Use of Passwords for Controlled Access to Computer Resources, NBS Special Publication 500-9, U.S. Department of Commerce, National Bureau of Standards, May 1977.
	8. National Bureau of Standards. Federal Information Processing Standards Publication 112, Password Usage Standard, 30 May 1985.
	9. National Bureau of Standards. Federal Information Processing Standards Publication 46, Data Encryption Standards, 15 January 1977.
	10. National Bureau of Standards. Federal Information Processing Standards Publication 81, DES Modes of Operation, 2 December 1980.