Computer Passwords Administration

A solution to this local password management problem is the use of randomly generated passwords, unique to each machine, and a central password database that is used to keep track of local passwords on client machines. Such a database should be strongly secured and access to it limited to only the minimum needed.

Specific security controls to implement include only permitting authorized administrators from authorized hosts to access the data, requiring strong authentication to access the database (for example, multi-factor authentication), storing the passwords in the database in an encrypted form (e.g., cryptographic hash), and requiring administrators to verify the identity of the database server before providing authentication credentials to it.

Another solution to management of local account passwords is to generate passwords based on system characteristics such as machine name or media access control (MAC) address. For example, the local password could be based on a cryptographic hash of the MAC address and a standard password. A machine's MAC address, "00:16:59:7F:2C:4D", could be combined with the password "N1stSPsRul308" to form the string "00:16:59:7F:2C:4D N1stSPsRul308". This string could be hashed using SHA and the first 20 characters of the hash used as the password for the machine.

This would create a pseudo-salt that would prevent many attackers from discovering that there is a shared password. However, if an attacker recovers one local password, the attacker would be able to determine other local passwords relatively easily.

Regardless of the method chosen, a solution should be implemented that prevents the use of shared local account passwords across many systems.

An attacker can successfully authenticate to an account by replacing the account's existing password with another password that is known by the attacker.

The attacker does not necessarily need to know the original password to accomplish this-for example, the attacker could intercept a user's legitimate attempt to reset a password. This section describes several ways in which attackers can replace passwords to gain access to accounts.

When a user forgets a password, generally there are two options: regain access to the old password-password recovery-or set a new password-a password reset. Password resets are also performed when a new account is created, to set an initial password. There are many ways in which password recovery and resets can be conducted-ranging from an in-person visit with an IT staff member to a fully automated self-service utility. If the identity of the user requesting a password recovery or reset is not properly verified, an attacker could easily pose as a user and gain access to that user's password, so all recovery and reset mechanisms should first verify the user's identity.

Examples of verification methods include basic knowledge-based verification (e.g. employee ID number, badge number, date of birth); predetermined challenge response questions set during account creation (e.g., color of first car, favorite pet's name); calling a user back on an office phone; and requiring a face-to-face visit from the user to provide photo identification.

Each verification method has advantages and disadvantages that should be evaluated before use. Privacy concerns should be carefully evaluated; for example, information such as social security numbers and mother's maiden name should not be used for identity verification.

User verification should not include data or question answers that can be easily obtained or guessed by an attacker, such as an employee ID number available from a company directory. For each password recovery or reset mechanism, the thoroughness of the user verification can be tailored to the account's relative security needs-for example, organizations might want to require a rigorous, out-of-band verification method for the highest-security passwords and use less rigorous methods for other cases.

When selecting verification methods, organizations should consider the relative risk of each method as opposed to its cost and convenience. Organizations should also identify and address any requirements to perform password recovery and resets for people who are not physically located in the organization's main facilities, including users who telecommute or are on travel.

The confidentiality of all sensitive information stored and transmitted as part of password recovery and resets should be protected. For example, if predetermined challenge-response questions or password hint questions are used to verify identity, the confidentiality of the answers should be protected at all times, and the confidentiality of the questions should also be protected if the questions are user-generated or otherwise differ among users.

Organizations should also carefully consider using filters to ensure that the answers set by a user to challenge-response questions have reasonable entropy, such as not using the same answer for each question and not using all one-character answers.

Organizations should send reset passwords through cleartext email messages and other unsecured applications only in the lowest-security situations because of the risk of interception by attackers.

Attackers may be able to replace passwords by gaining access to stored user account information and passwords. For example, a host may have incorrect privileges set on its password files that allow a user to overwrite them. The user could set new passwords for others' accounts or create new accounts. A similar attack can be accomplished on many hosts if an attacker gains physical access to the host. There are password reset tools and utilities that can permit an attacker with physical access to reset the built-in administrator account password. Section 3.1.1 contains recommendations for securing stored passwords.

Attackers may be able to trick users into changing their existing passwords to attacker-selected passwords by using social engineering techniques.

Computer Security - Cryptography
Development of a Cryptographic Module
Cryptographic Module Guidance
Cryptography - Security Levels
Cryptographic Module Finite State Model
Cryptographic Modules - Design
Configuration Management
Conditional Self-Tests
Pre-Operational Self-Test
SSP Zeroization
SSP Entry and Output
Environmental Failure Testing Procedures
Single-Chip Cryptographic Modules
Multiple-Chip Standalone and Embeded Cryptographic Modules
Cryptographic Module Specification
Software and Services
Operator Authentication & Logical Interfaces
Cryptography - Acronyms