CSC-STD-002-85

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.

ii

CONTENTS

FOREWORD..................................................... i

ACKNOWLEDGMENTS.............................................. ii

CONTENTS......................................................iii

INTRODUCTION................................................. 1

1.0

SCOPE...........................................................1

2.0 CONTROL OBJECTIVES..................................... ....2

3.0 DEFINTIONS............................................... 3

4.0 GUIDELINES.............................................. 4

4.1 SSO Responsibilities.................................. 4

4.1.1 Initial System Passwords............... 4

4.1.2 Initial Password Assignment............... 4

4.1.3 Password Change Authorization............. 6

4.1.4 Group IDs................................ 6

4.1.5 User ID Revalidation....................... 6

4.2 User Responsibilities.............................. 6

4.2.1 Security Awareness........................ 6

4.2.2 Changing Passwords........................ 6

4.2.3 Log into a Connected System.................. 8

4.2.4 Remembering Passwords.................... 8

4.3 Authentication Mechanism Functionality............ 9

4.3.1 Internal Storage of Passwords ............. 9

4.3.2 Entry...................................... 9

4.3.3 Transmission............................... 10

4.3.4 Login Attempt Rate......................... 10

4.3.5 Auditing.................................... 10

4.4 Password Protection.............................. 11

4.4.1 Single Guess Probability.................. 11

4.4.2 Password Distribution ...................... 11

APPENDIX A: Password Generation Algorithm................... 13

APPENDIX B: Password Encryption Algorithm................... 13

APPENDIX C: Determining Password Length..................... 17

iii

APPENDIX D: Protection Basis for Passwords.............. 23

APPENDIX E: Features for Use in Very Sensitive Applications 25

APPENDIX F: On the Probability of Guessing a Password..... 27

REFERENCES.................................................. 31

iv

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

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 550 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.

5

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. 13 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.

6

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

7

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

8

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 angenerated 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.

9

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 an-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

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.

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

10

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 reasonto 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.

Auditableevents should include: successful login, unsuccessful login

11

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 11'). 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 consecutiveunsuccessful 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

12

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 550 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.

13

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 5 A where 5 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

14

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 550).

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.

15

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.)

16

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

continuous 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

password 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

[I]

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.

16

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

[2]

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.,

AZ):

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.

19

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, 5, with the equation derived

from equation [1]

S = G

[3]

P

where G L x R

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

M = log S

[4]

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:

20

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 Length of Password

LIFETIME

(months)

26-Character alphabet 36-Character alphabet

6 9 8

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

12 9 8

(rounded up from 8.94) (rounded down from 8.13)

21

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 5 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, 5=4.4676*1012, log S = 12.6500

For L = 6 months, 5=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.

23

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 AD P 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 For Official Use Only information. 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.

24

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.

25

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.

27

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 5 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:

s!

g!(s-g)!

Thus, if 5 - 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.

28

(Enumerating, they are ABC~ABD,ABE,ACD,ACE,ADE,BCD,BCE,BDE~C~~.) 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 5, 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

29

Evaluating this expression gives:

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

P = (g-1)!((s-1)-(g1))! = (g-1)1(s-g)! = g!(s-1)! = g

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]

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.

30

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.