I-0120: Additional Protection Required For Passwords

NUMBER:               I-0120
STATUS:               Ready to Prepare for Management/CCIMB

TITLE:                Additional Protection Required For Passwords

FIRST POST:            [criteria 2088]
MOST RECENT REPOST:    [criteria 2159]

REQUIREMENT:          Identification and Authentication
CRITERIA CLASSES:     C1, C2, B1, B2, B3, A1
DOCUMENT(S):          <None>
RELATED TO:           <None>

STATEMENT:

The following interprets the requirements that ``The TCB shall protect authentication data so that it cannot be accessed by any unauthorized user.''

Once data has been stored in permanent storage for authentication purposes, the raw form shall be available only to the TCB's authentication mechanism(s) and related administrative utilities.

PROJECTED IMPACT:

Minimal. Most, perhaps all, evaluated products have this capability.

SUPPORT:

In the interpretation, the ``raw'' form is a form of the authentication data that can be provided across the TCB interface for authentication, such as an unencrypted password. The raw form would also apply to the sequence of bits that would represent a biometric signature, if there was the potential to insert that sequence of bits across the TCB interface (e.g., replay threats across an unprotected network line). Note that the raw form must have the potential for reuse; thus single-use passwords are not considered to be in ``raw'' form unless there is a significant threat of successful replay (as might be the case in a system that used a small number of fixed passwords in a cycle).

Approaches that satisfy this interpretation include the storage of one-way hashed authentication data in databases restricted to TCB use, or the storage of raw authentication data in the TCB such that the TCB ensures that only authentication mechanisms have access to the data, and the raw form is never disclosed to a unauthorized user once stored. For one-way hashing there is no judgement of the strength of the hash function other than that is it not obviously a many-to-one translation.

The sole use of authentication data is for authenticating the user. Because there is no other authorized use of this data, the requirement for protection calls for protection against access even by privileged users who may be able to override MAC or DAC controls.

This interpretation provides protection against accidental disclosure, and increases the effort required to obtain authentication data without authorization even by privileged users.

This interpretation permits authentication data to be stored as character strings (e.g. one-way hashed and translated to printable characters), as long as this form cannot itself be used for authentication. However, such storage (as for all authentication data storage) must also be protected against ordinary user access (see interpretation #0326). The interpretation would also permit the authentication data for a user to be stored in a raw form; however, this raw form would have to be stored in such a way that it is accessible only to the authentication mechanism and related administative utilities and cannot be accessed through the TCB for any other purposes or by a user other than the user that the data authenticates (e.g., on a PROM on the system board that is addressible only by the kernel's authentication mechanism).

The term ``permanent storage'' is meant to cover the storage that the TCB uses for management of authentication data, but not other storage (e.g., memory buffers, crash dumps) where authentication data may appear during the course of normal system operation.

The method used to translate the authentication data to a non-raw form should not decrease the space of available authentication data; i.e., the raw to non-raw mapping should not be many-to-one.