|IA-5 (1) Password-Based Authentication ||LOW |
This control enhancement applies to single-factor authentication of individuals using passwords as individual or group authenticators, and in a similar manner, when passwords are part of multifactor authenticators. This control enhancement does not apply when passwords are used to unlock hardware authenticators (e.g., Personal Identity Verification cards). The implementation of such password mechanisms may not meet all of the requirements in the enhancement. Cryptographically-protected passwords include, for example, encrypted versions of passwords and one-way cryptographic hashes of passwords. The number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. Password lifetime restrictions do not apply to temporary passwords. To mitigate certain brute force attacks against passwords, organizations may also consider salting passwords.
The information system, for password-based authentication: IA-5 (1)(a)
Enforces minimum password complexity of Assignment: organization-defined requirements for case sensitivity, number of characters, mix of upper-case letters, lower-case letters, numbers, and special characters, including minimum requirements for each type; IA-5 (1)(b)
Enforces at least the following number of changed characters when new passwords are created: Assignment: organization-defined number; IA-5 (1)(c)
Stores and transmits only cryptographically-protected passwords; IA-5 (1)(d)
Enforces password minimum and maximum lifetime restrictions of Assignment: organization-defined numbers for lifetime minimum, lifetime maximum; IA-5 (1)(e)
Prohibits password reuse for Assignment: organization-defined number generations; and IA-5 (1)(f)
Allows the use of a temporary password for system logons with an immediate change to a permanent password.
|IA-5 (2) Pki-Based Authentication ||MODERATE |
Status information for certification paths includes, for example, certificate revocation lists or certificate status protocol responses. For PIV cards, validation of certifications involves the construction and verification of a certification path to the Common Policy Root trust anchor including certificate policy processing.
The information system, for PKI-based authentication: IA-5 (2)(a)
Validates certifications by constructing and verifying a certification path to an accepted trust anchor including checking certificate status information; IA-5 (2)(b)
Enforces authorized access to the corresponding private key; IA-5 (2)(c)
Maps the authenticated identity to the account of the individual or group; and IA-5 (2)(d)
Implements a local cache of revocation data to support path discovery and validation in case of inability to access revocation information via the network.
|IA-5 (3) In-Person Or Trusted Third-Party Registration ||MODERATE |
The organization requires that the registration process to receive Assignment: organization-defined types of and/or specific authenticators be conducted Selection: in person; by a trusted third party before Assignment: organization-defined registration authority with authorization by Assignment: organization-defined personnel or roles.
|IA-5 (4) Automated Support For Password Strength Determination || |
This control enhancement focuses on the creation of strong passwords and the characteristics of such passwords (e.g., complexity) prior to use, the enforcement of which is carried out by organizational information systems in IA-5 (1).
The organization employs automated tools to determine if password authenticators are sufficiently strong to satisfy Assignment: organization-defined requirements.
|IA-5 (5) Change Authenticators Prior To Delivery || |
This control enhancement extends the requirement for organizations to change default authenticators upon information system installation, by requiring developers and/or installers to provide unique authenticators or change default authenticators for system components prior to delivery and/or installation. However, it typically does not apply to the developers of commercial off-the-shelve information technology products. Requirements for unique authenticators can be included in acquisition documents prepared by organizations when procuring information systems or system components.
The organization requires developers/installers of information system components to provide unique authenticators or change default authenticators prior to delivery/installation.
|IA-5 (6) Protection Of Authenticators || |
For information systems containing multiple security categories of information without reliable physical or logical separation between categories, authenticators used to grant access to the systems are protected commensurate with the highest security category of information on the systems.
The organization protects authenticators commensurate with the security category of the information to which use of the authenticator permits access.
|IA-5 (7) No Embedded Unencrypted Static Authenticators || |
Organizations exercise caution in determining whether embedded or stored authenticators are in encrypted or unencrypted form. If authenticators are used in the manner stored, then those representations are considered unencrypted authenticators. This is irrespective of whether that representation is perhaps an encrypted version of something else (e.g., a password).
The organization ensures that unencrypted static authenticators are not embedded in applications or access scripts or stored on function keys.
|IA-5 (8) Multiple Information System Accounts || |
When individuals have accounts on multiple information systems, there is the risk that the compromise of one account may lead to the compromise of other accounts if individuals use the same authenticators. Possible alternatives include, for example: (i) having different authenticators on all systems; (ii) employing some form of single sign-on mechanism; or (iii) including some form of one-time passwords on all systems.
The organization implements Assignment: organization-defined security safeguards to manage the risk of compromise due to individuals having accounts on multiple information systems.
|IA-5 (9) Cross-Organization Credential Management || |
Cross-organization management of credentials provides the capability for organizations to appropriately authenticate individuals, groups, roles, or devices when conducting cross-organization activities involving the processing, storage, or transmission of information.
The organization coordinates with Assignment: organization-defined external organizations for cross-organization management of credentials.
|IA-5 (10) Dynamic Credential Association || |
Authentication requires some form of binding between an identity and the authenticator used to confirm the identity. In conventional approaches, this binding is established by pre-provisioning both the identity and the authenticator to the information system. For example, the binding between a username (i.e., identity) and a password (i.e., authenticator) is accomplished by provisioning the identity and authenticator as a pair in the information system. New authentication techniques allow the binding between the identity and the authenticator to be implemented outside an information system. For example, with smartcard credentials, the identity and the authenticator are bound together on the card. Using these credentials, information systems can authenticate identities that have not been pre-provisioned, dynamically provisioning the identity after authentication. In these situations, organizations can anticipate the dynamic provisioning of identities. Preestablished trust relationships and mechanisms with appropriate authorities to validate identities and related credentials are essential.
The information system dynamically provisions identities.
|IA-5 (11) Hardware Token-Based Authentication ||LOW |
Hardware token-based authentication typically refers to the use of PKI-based tokens, such as the U.S. Government Personal Identity Verification (PIV) card. Organizations define specific requirements for tokens, such as working with a particular PKI.
The information system, for hardware token-based authentication, employs mechanisms that satisfy Assignment: organization-defined token quality requirements.
|IA-5 (12) Biometric Authentication || |
Unlike password-based authentication which provides exact matches of user-input passwords to stored passwords, biometric authentication does not provide such exact matches. Depending upon the type of biometric and the type of collection mechanism, there is likely to be some divergence from the presented biometric and stored biometric which serves as the basis of comparison. There will likely be both false positives and false negatives when making such comparisons. The rate at which the false accept and false reject rates are equal is known as the crossover rate. Biometric quality requirements include, for example, acceptable crossover rates, as that essentially reflects the accuracy of the biometric.
The information system, for biometric-based authentication, employs mechanisms that satisfy Assignment: organization-defined biometric quality requirements.
|IA-5 (13) Expiration Of Cached Authenticators || |
The information system prohibits the use of cached authenticators after Assignment: organization-defined time period.
|IA-5 (14) Managing Content Of Pki Trust Stores || |
The organization, for PKI-based authentication, employs a deliberate organization-wide methodology for managing the content of PKI trust stores installed across all platforms including networks, operating systems, browsers, and applications.
|IA-5 (15) Ficam-Approved Products And Services || |
Federal Identity, Credential, and Access Management (FICAM)-approved path discovery and validation products and services are those products and services that have been approved through the FICAM conformance program, where applicable.
The organization uses only FICAM-approved path discovery and validation products and services.