Identification and Authentication (IA)¶

IA.L2-3.5.1 – Identification [CUI Data]¶

Identify system users, processes acting on behalf of users, and devices.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 31.

Determine if:

• [a] system users are identified;
• [b] processes acting on behalf of users are identified; and
• [c] devices accessing the system are identified.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 31.

Examine: [SELECT FROM: Identification and authentication policy; procedures addressing user identification and authentication; system security plan, system design documentation; system configuration settings and associated documentation; system audit logs and records; list of system accounts; other relevant documents or records].

Interview: [SELECT FROM: Personnel with system operations responsibilities; personnel with information security responsibilities; system or network administrators; personnel with account management responsibilities; system developers].

Test: [SELECT FROM: Organizational processes for uniquely identifying and authenticating users; mechanisms supporting or implementing identification and authentication capability].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 23.

Common device identifiers include media access control (MAC), Internet Protocol (IP) addresses, or device-unique token identifiers. Management of individual identifiers is not applicable to shared system accounts. Typically, individual identifiers are the user names associated with the system accounts assigned to those individuals. Organizations may require unique identification of individuals in group accounts or for detailed accountability of individual activity. In addition, this requirement addresses individual identifiers that are not necessarily associated with system accounts. Organizational devices requiring identification may be defined by type, by device, or by a combination of type/device. NIST SP 800-63-3 provides guidance on digital identities.

Further Discussion¶

Make sure to assign individual, unique identifiers (e.g., user names) to all users and processes that access company systems. Authorized devices also should have unique identifiers. Unique identifiers can be as simple as a short set of alphanumeric characters (e.g., SW001 could refer to a network switch, SW002 could refer to a different network switch). This requirement, IA.L2-3.5.1, provides a vetted and trusted identity that supports the access control mechanism required by AC.L2-3.1.1.

Examples¶

• You want to make sure that all employees working on a project can access important information about it. Because this is work for the DoD and may contain CUI, you also need to prevent employees who are not working on that project from being able to access the information. You assign each employee is assigned a unique user ID, which they use to log into the system [a].

Potential Assessment Considerations¶

• Are unique identifiers issued to individual users (e.g., usernames) [a]?
• Are the processes and service accounts that an authorized user initiates identified (e.g., scripts, automatic updates, configuration updates, vulnerability scans) [b]?
• Are unique device identifiers used for devices that access the system identified [c]?

Key References¶

• NIST SP 800-171 Rev. 2 3.5.1
• FAR Clause 52.204-21 b.1.v

IA.L2-3.5.2 – Authentication [CUI Data]¶

Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 31.

Determine if:

• [a] the identity of each user is authenticated or verified as a prerequisite to system access;
• [b] the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access; and
• [c] the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 31.

Examine: [SELECT FROM: Identification and authentication policy; system security plan; procedures addressing authenticator management; procedures addressing user identification and authentication; system design documentation; list of system authenticator types; system configuration settings and associated documentation; change control records associated with managing system authenticators; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: Personnel with authenticator management responsibilities; personnel with information security responsibilities; system or network administrators].

Test: [SELECT FROM: Mechanisms supporting or implementing authenticator management capability].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 24.

Individual authenticators include the following: passwords, key cards, cryptographic devices, and one-time password devices. Initial authenticator content is the actual content of the authenticator, for example, the initial password. In contrast, the requirements about authenticator content include the minimum password length. Developers ship system components with factory default authentication credentials to allow for initial installation and configuration. Default authentication credentials are often well known, easily discoverable, and present a significant security risk. Systems support authenticator management by organization-defined settings and restrictions for various authenticator characteristics including minimum password length, validation time window for time synchronous one-time tokens, and number of allowed rejections during the verification stage of biometric authentication. Authenticator management includes issuing and revoking, when no longer needed, authenticators for temporary access such as that required for remote maintenance. Device authenticators include certificates and passwords. NIST SP 800-63-3 provides guidance on digital identities.

Further Discussion¶

Before a person or device is given system access, verify that the user or device is who or what it claims to be. This verification is called authentication. The most common way to verify identity is using a username and a hard-to-guess password. Some devices ship with default usernames and passwords. Some devices ship with a default username (e.g., admin) and password. A default username and password must be immediately changed to something unique. Default passwords may be well known to the public, easily found in a search, or easy to guess, allowing an unauthorized person to access the system.

Examples¶

• You are in charge of purchasing. You know that some laptops come with a default username and password. You notify IT that all default passwords should be reset prior to laptop use [a]. You ask IT to explain the importance of resetting default passwords and convey how easily they are discovered using internet searches during next week’s cybersecurity awareness training.

• Your company decides to use cloud services for email and other capabilities. Upon reviewing this requirement, you realize every user or device that connects to the cloud service must be authenticated. As a result, you work with your cloud service provider to ensure that only properly authenticated users and devices are allowed to connect to the system [a,c].

Potential Assessment Considerations¶

• Are unique authenticators used to verify user identities (e.g., passwords) [a]?
• An example of a process acting on behalf of users could be a script that logs in as a person or service account [b]. Can the OSA show that it maintains a record of all of those service accounts for use when reviewing log data or responding to an incident?
• Are user credentials authenticated in system processes (e.g., credentials binding, certificates, tokens) [b]?
• Are device identifiers used in authentication processes (e.g., MAC address, non-anonymous computer name, certificates) [c]?

Key References¶

• NIST SP 800-171 Rev. 2 3.5.2
• FAR Clause 52.204-21 b.1.vi

IA.L2-3.5.3 – Multifactor Authentication¶

Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 32.

Determine if:

• [a] privileged accounts are identified;
• [b] multifactor authentication is implemented for local access to privileged accounts;
• [c] multifactor authentication is implemented for network access to privileged accounts; and
• [d] multifactor authentication is implemented for network access to non-privileged accounts.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 32.

Examine: [SELECT FROM: Identification and authentication policy; procedures addressing user identification and authentication; system security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; list of system accounts; other relevant documents or records].

Interview: [SELECT FROM: Personnel with authenticator management responsibilities; personnel with information security responsibilities; system or network administrators].

Test: [SELECT FROM: Mechanisms supporting or implementing authenticator management capability].

Discussion¶

Source: NIST SP 800-171 Rev. 2, pp. 24-25.

Multifactor authentication requires the use of two or more different factors to authenticate. The factors are defined as something you know (e.g., password, personal identification number [PIN]); something you have (e.g., cryptographic identification device, token); or something you are (e.g., biometric). Multifactor authentication solutions that feature physical authenticators include hardware authenticators providing time-based or challenge-response authenticators and smart cards. In addition to authenticating users at the system level (i.e., at logon), organizations may also employ authentication mechanisms at the application level, when necessary, to provide increased information security. Access to organizational systems is defined as local access or network access. Local access is any access to organizational systems by users (or processes acting on behalf of users) where such access is obtained by direct connections without the use of networks. Network access is access to systems by users (or processes acting on behalf of users) where such access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks. The use of encrypted virtual private networks for connections between organization-controlled and non-organization controlled endpoints may be treated as internal networks with regard to protecting the confidentiality of information. NIST SP 800-63-3 provides guidance on digital identities.

Further Discussion¶

Implement a combination of two or more factors of authentication to verify privileged account holders’ identity regardless of how the user is accessing the account. Implement a combination of two or more factors for non-privileged users accessing the system over a network. The implementation of multi-factor authentication will depend on the environment and business needs. Although two-factor authentication directly on the computer is most common, there are situations (e.g., multi-factor identification for a mission system that cannot be altered) where additional technical or physical solutions can provide security. If a mobile device is used to access a system or application containing CUI, multi-factor authentication is required. This requirement, IA.L2-3.5.3, requires multifactor authentication for network access to non-privileged accounts and complements five other requirements dealing with remote access (AC.L2-3.1.12, AC.L2-3.1.14, AC.L2-3.1.13, AC.L2-3.1.15, and MA.L2-3.7.5:

• AC.L2-3.1.12 requires the control of remote access sessions.
• AC.L2-3.1.14 limits remote access to specific access control points.
• AC.L2-3.1.13 requires the use of cryptographic mechanisms when enabling remote sessions.
• AC.L2-3.1.15 requires authorization for privileged commands executed during a remote.
• Finally, MA.L2-3.7.5 requires the addition of multifactor authentication for remote maintenance sessions.

This requirement, IA.L2-3.5.3, also enhances IA.L2-3.5.2, which is a requirement for a less rigorous form of user authentication.

Examples¶

• You decide to implement multifactor authentication (MFA) to improve security of your network. Your first step is enabling MFA on VPN access to your internal network [c,d]. When users initiate remote access, they will be prompted for the additional authentication factor.

Because you also use a cloud-based email solution, you require MFA for access to that resource as well [c,d]. Finally, you enable MFA for both local and network logins for the system administrator accounts used to patch and manage servers [a,b,c].

Potential Assessment Considerations¶

• Does the system uniquely identify and authenticate users, including privileged accounts [b,c,d]?

Key References¶

• NIST SP 800-171 Rev. 2 3.5.3

IA.L2-3.5.4 – Replay-Resistant Authentication¶

Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 32.

Determine if:

• [a] replay-resistant authentication mechanisms are implemented for network account access to privileged and non-privileged accounts.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 32.

Examine: [SELECT FROM: Identification and authentication policy; procedures addressing user identification and authentication; system security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; list of privileged system accounts; other relevant documents or records].

Interview: [SELECT FROM: Personnel with system operations responsibilities; personnel with account management responsibilities; personnel with information security responsibilities; system or network administrators; system developers].

Test: [SELECT FROM: Mechanisms supporting or implementing identification and authentication capability or replay resistant authentication mechanisms].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 25.

Authentication processes resist replay attacks if it is impractical to successfully authenticate by recording or replaying previous authentication messages. Replay-resistant techniques include protocols that use nonces or challenges such as time synchronous or challenge-response one-time authenticators. NIST SP 800-63-3 provides guidance on digital identities.

Further Discussion¶

When insecure protocols are used for access to computing resources, an adversary may be able to capture login information and immediately reuse (replay) it for other purposes. It is important to use mechanisms that resist this technique.

Examples¶

• To protect your IT infrastructure, you understand that the methods for authentication must not be easily copied and re-sent to your systems by an adversary. You select Kerberos for authentication because of its built-in resistance to replay attacks. As a next step you upgrade all of your web applications to require Transport Layer Security (TLS), which also is replay-resistant. Your use of MFA to protect remote access also confers some replay resistance.

Potential Assessment Considerations¶

• Are only anti-replay authentication mechanisms used [a]?

Key References¶

• NIST SP 800-171 Rev. 2 3.5.4

IA.L2-3.5.5 – Identifier Reuse¶

Prevent reuse of identifiers for a defined period.

Assessment Objectives¶

Source: NIST SP 800-171A, pp. 32-33.

Determine if:

• [a] a period within which identifiers cannot be reused is defined; and
• [b] reuse of identifiers is prevented within the defined period.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, pp. 32-33.

Examine: [SELECT FROM: Identification and authentication policy; system security plan; procedures addressing authenticator management; procedures addressing user identification and authentication; system design documentation; list of system authenticator types; system configuration settings and associated documentation; change control records associated with managing system authenticators; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: Personnel with authenticator management responsibilities; personnel with information security responsibilities; system or network administrators].

Test: [SELECT FROM: Mechanisms supporting or implementing authenticator management capability].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 25.

Identifiers are provided for users, processes acting on behalf of users, or devices (IA.L2-3.5.1). Preventing reuse of identifiers implies preventing the assignment of previously used individual, group, role, or device identifiers to different individuals, groups, roles, or devices.

Further Discussion¶

Identifiers uniquely associate a user ID to an individual, group, role, or device. Establish guidelines and implement mechanisms to prevent identifiers from being reused for the period of time established in the policy.

Examples¶

• As a system administrator, you maintain a central directory/domain that holds the accounts for users, computers, and network devices. As part of your job, you issue unique usernames (e.g., riley@acme.com) for the staff to access resources. When you issue staff computers you also rename the computer to reflect to whom it is assigned (e.g., riley-laptop01). Riley has recently left the organization, so you must manage the former staff member’s account. Incidentally, their replacement is also named Riley. In the directory, you do not assign the previous account to the new user, as policy has defined an identifier reuse period of 24 months [a]. In accordance with policy, you create an account called riley02 [b]. This account is assigned the appropriate permissions for the new user. A new laptop is also provided with the identifier of riley02-laptop01.

Potential Assessment Considerations¶

• Are accounts uniquely assigned to employees, contractors, and subcontractors [b]?
• Are account identifiers reused [b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.5.5

IA.L2-3.5.6 – Identifier Handling¶

Disable identifiers after a defined period of inactivity.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 33.

Determine if:

• [a] a period of inactivity after which an identifier is disabled is defined; and
• [b] identifiers are disabled after the defined period of inactivity.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 33.

Examine: [SELECT FROM: Identification and authentication policy; procedures addressing identifier management; procedures addressing account management; system security plan; system design documentation; system configuration settings and associated documentation; list of system accounts; list of identifiers generated from physical access control devices; other relevant documents or records].

Interview: [SELECT FROM: Personnel with identifier management responsibilities; personnel with information security responsibilities; system or network administrators; system developers].

Test: [SELECT FROM: Mechanisms supporting or implementing identifier management].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 25.

Inactive identifiers pose a risk to organizational information because attackers may exploit an inactive identifier to gain undetected access to organizational devices. The owners of the inactive accounts may not notice if unauthorized access to the account has been obtained.

Further Discussion¶

Identifiers are uniquely associated with an individual, account, process, or device. An inactive identifier is one that has not been used for a defined extended period of time. For example, a user account may be needed for a certain time to allow for transition of business processes to existing or new staff. Once use of the identifier is no longer necessary, it should be disabled as soon as possible. Failure to maintain awareness of accounts that are no longer needed yet still active could allow an adversary to exploit IT services.

Examples¶

• One of your responsibilities is to enforce your company’s inactive account policy: any account that has not been used in the last 45 days must be disabled [a]. You enforce this by writing a script that runs once a day to check the last login date for each account and generates a report of the accounts with no login records for the last 45 days. After reviewing the report, you notify each inactive employee’s supervisor and disable the account [b].

Potential Assessment Considerations¶

• Are user accounts or identifiers monitored for inactivity [b]?

Key References¶

• NIST SP 800-171 Rev. 2 3.5.6

IA.L2-3.5.7 – Password Complexity¶

Enforce a minimum password complexity and change of characters when new passwords are created.

Assessment Objectives¶

Source: NIST SP 800-171A, pp. 33-34.

Determine if:

• [a] password complexity requirements are defined;
• [b] password change of character requirements are defined;
• [c] minimum password complexity requirements as defined are enforced when new passwords are created; and
• [d] minimum password change of character requirements as defined are enforced when new passwords are created.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, pp. 33-34.

Examine: [SELECT FROM: Identification and authentication policy; password policy; procedures addressing authenticator management; system security plan; system configuration settings and associated documentation; system design documentation; password configurations and associated documentation; other relevant documents or records].

Interview: [SELECT FROM: Personnel with authenticator management responsibilities; personnel with information security responsibilities; system or network administrators].

Test: [SELECT FROM: Mechanisms supporting or implementing authenticator management capability].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 25.

This requirement applies to single-factor authentication of individuals using passwords as individual or group authenticators, and in a similar manner, when passwords are used as part of multifactor authenticators. The number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. To mitigate certain brute force attacks against passwords, organizations may also consider salting passwords.

Further Discussion¶

Password complexity means using different types of characters as well as a specified number of characters. This applies to both the creation of new passwords and the modification of existing passwords. Characters to manage complexity include numbers, lowercase and uppercase letters, and symbols. Minimum complexity requirements are left up to the organization to define. Define the lowest level of password complexity required. Define the number of characters that must be changed when an existing password is changed. Enforce these rules for all passwords. Salting passwords adds a string of random characters (salt) to a password prior to hashing. This ensures the randomness of the resulting hash value.

Examples¶

• You work with management to define password complexity rules and ensure they are listed in the company’s security policy. You define and enforce a minimum number of characters for each password and ensure that a certain number of characters must be changed when updating passwords [a,b]. Characters include numbers, lowercase and uppercase letters, and symbols [a]. These rules help create hard-to-guess passwords, which help to secure your network.

Potential Assessment Considerations¶

• Is a degree of complexity specified for passwords, (e.g., are account passwords a minimum of 12 characters and a mix of upper/lower case, numbers, and special characters), including minimum requirements for each type [a,b,c]?
• Is a change of characters required when new passwords are created [d]?

Key References¶

• NIST SP 800-171 Rev. 2 3.5.7

IA.L2-3.5.8 – Password Reuse¶

Prohibit password reuse for a specified number of generations.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 34.

Determine if:

• [a] the number of generations during which a password cannot be reused is specified and
• [b] reuse of passwords is prohibited during the specified number of generations.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 34.

Examine: [SELECT FROM: Identification and authentication policy; password policy; procedures addressing authenticator management; system security plan; system design documentation; system configuration settings and associated documentation; password configurations and associated documentation; other relevant documents or records].

Interview: [SELECT FROM: Personnel with authenticator management responsibilities; personnel with information security responsibilities; system or network administrators; system developers].

Test: [SELECT FROM: Mechanisms supporting or implementing password-based authenticator management capability].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 25.

Password lifetime restrictions do not apply to temporary passwords.

Further Discussion¶

Individuals may not reuse their passwords for a defined period of time and a set number of passwords generated.

Examples¶

• You explain in your company’s security policy that changing passwords regularly provides increased security by reducing the ability of adversaries to exploit stolen or purchased passwords over an extended period. You define how often individuals can reuse their passwords and the minimum number of password generations before reuse [a]. If a user tries to reuse a password before the number of password generations has been exceeded, an error message is generated, and the user is required to enter a new password [b].

Potential Assessment Considerations¶

• How many generations of password changes need to take place before a password can be reused [a]?

Key References¶

• NIST SP 800-171 Rev. 2 3.5.8

IA.L2-3.5.9 – Temporary Passwords¶

Allow temporary password use for system logons with an immediate change to a permanent password.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 34.

Determine if:

• [a] an immediate change to a permanent password is required when a temporary password is used for system logon.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 34.

Examine: [SELECT FROM: Identification and authentication policy; password policy; procedures addressing authenticator management; system security plan; system configuration settings and associated documentation; system design documentation; password configurations and associated documentation; other relevant documents or records].

Interview: [SELECT FROM: Personnel with authenticator management responsibilities; personnel with information security responsibilities; system or network administrators; system developers].

Test: [SELECT FROM: Mechanisms supporting or implementing password-based authenticator management capability].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 25.

Changing temporary passwords to permanent passwords immediately after system logon ensures that the necessary strength of the authentication mechanism is implemented at the earliest opportunity, reducing the susceptibility to authenticator compromises.

Further Discussion¶

Users must change their temporary passwords the first time they log in. Temporary passwords often follow a consistent style within an organization and can be more easily guessed than passwords created by the unique user. This approach to temporary passwords should be avoided.

Examples¶

• One of your duties as a systems administrator is to create accounts for new users. You configure all systems with user accounts to require users to change a temporary password upon initial login to a permanent password [a]. When a user logs on for the first time, they are prompted to create a unique password that meets all of the defined complexity rules.

Potential Assessment Considerations¶

• Are temporary passwords only valid to allow a user to perform a password reset [a]?
• Does the system enforce an immediate password change after logon when a temporary password is issued [a]?

Key References¶

• NIST SP 800-171 Rev. 2 3.5.9

IA.L2-3.5.10 – Cryptographically-Protected Passwords¶

Store and transmit only cryptographically-protected passwords.

Assessment Objectives¶

Source: NIST SP 800-171A, pp. 34-35.

Determine if:

• [a] passwords are cryptographically protected in storage; and
• [b] passwords are cryptographically protected in transit.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, pp. 34-35.

Examine: [SELECT FROM: Identification and authentication policy; system security plan; procedures addressing authenticator management; procedures addressing user identification and authentication; system design documentation; list of system authenticator types; system configuration settings and associated documentation; change control records associated with managing system authenticators; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: Personnel with authenticator management responsibilities; personnel with information security responsibilities; system or network administrators].

Test: [SELECT FROM: Mechanisms supporting or implementing authenticator management capability].

Discussion¶

Source: NIST SP 800-171 Rev. 2, pp. 25-26.

Cryptographically-protected passwords use salted one-way cryptographic hashes of passwords. See NIST Cryptographic Standards and Guidelines.

Further Discussion¶

All passwords must be cryptographically protected using a one-way function for storage and transmission. This type of protection changes passwords into another form, or a hashed password. A one-way transformation makes it theoretically impossible to turn the hashed password back into the original password, but inadequate complexity (IA.L2-3.5.7) may still facilitate offline cracking of hashes.

Examples¶

• You are responsible for managing passwords for your organization. You protect all passwords with a one-way transformation, or hashing, before storing them. Passwords are never transmitted across a network unencrypted [a,b].

Potential Assessment Considerations¶

• Are passwords prevented from being stored in reversible encryption form in any company systems [a]?
• Are passwords stored as one-way hashes constructed from passwords [a]?

Key References¶

• NIST SP 800-171 Rev. 2 3.5.10

IA.L2-3.5.11 – Obscure Feedback¶

Obscure feedback of authentication information.

Assessment Objectives¶

Source: NIST SP 800-171A, p. 35.

Determine if:

• [a] authentication information is obscured during the authentication process.

Potential Assessment Methods and Objects¶

Source: NIST SP 800-171A, p. 35.

Examine: [SELECT FROM: Identification and authentication policy; procedures addressing authenticator feedback; system security plan; system design documentation; system configuration settings and associated documentation; system audit logs and records; other relevant documents or records].

Interview: [SELECT FROM: Personnel with information security responsibilities; system or network administrators; system developers].

Test: [SELECT FROM: Mechanisms supporting or implementing the obscuring of feedback of authentication information during authentication].

Discussion¶

Source: NIST SP 800-171 Rev. 2, p. 26.

The feedback from systems does not provide any information that would allow unauthorized individuals to compromise authentication mechanisms. For some types of systems or system components, for example, desktop or notebook computers with relatively large monitors, the threat (often referred to as shoulder surfing) may be significant. For other types of systems or components, for example, mobile devices with small displays, this threat may be less significant, and is balanced against the increased likelihood of typographic input errors due to the small keyboards. Therefore, the means for obscuring the authenticator feedback is selected accordingly. Obscuring authenticator feedback includes displaying asterisks when users type passwords into input devices or displaying feedback for a very limited time before fully obscuring it.

Further Discussion¶

Authentication information includes passwords. When users enter a password, the system displays a symbol, such as an asterisk, to obscure feedback preventing others from seeing the actual characters. Feedback is obscured based on a defined policy (e.g., smaller devices may briefly show characters before obscuring).

Examples¶

• As a system administrator, you configure your systems to display an asterisk when users enter their passwords into a computer system [a]. For mobile devices, the password characters are briefly displayed to the user before being obscured. This prevents people from figuring out passwords by looking over someone’s shoulder.

Potential Assessment Considerations¶

• Is the feedback immediately obscured when the authentication is presented on a larger display (e.g., desktop or notebook computers with relatively large monitors) [a]?

Key References¶

• NIST SP 800-171 Rev. 2 3.5.11