Computer Security | Using Compromised Passwords

Organizations should decide whether to use password expiration mechanisms and what expiration period to set based on balancing security needs and usability. For example, if the organization provides secure storage for user passwords, so that users do not have to remember passwords, then password expiration will be less frustrating to users.

If there are significant threats involving unauthorized access to password hashes, then it may be necessary to set the expiration period to be less than the amount of time required to crack the passwords from the hashes, as discussed in the box below. Another consideration is the frequency of authentication; if an application is accessed only a few times a year by employees and password expiration is enforced, then the passwords will be expired every time the users attempt to authenticate.

Other factors for organizations to consider in selecting password expiration requirements include the strength of password storage and transmission algorithms and the system security requirements. Organizations should consider having different policies for password expiration for different types of systems, OSs, and applications, to reflect their varying security needs and usability requirements.

Because of advances in hardware and cracking software and the availability of large numbers of compromised computers through botnets, attackers are constantly increasing their ability to crack passwords.

The type of cryptographic algorithm used for the password hashes somewhat affects the cracking speed, but generally does not affect it enough to make cracking ineffective.

Security researchers and cracking software vendors claim hash generation speeds for some hash algorithms of hundreds of millions to over a billion per second per computer, with the ability to use thousands of computers simultaneously.11 Generating a billion hashes per second on each of a thousand machines would equal approximately 2.6 quintillion (2.6*1018) hashes per month.
In cases where password hashes are at significant risk of compromise, organizations should take estimates of cracking abilities into consideration when setting policies for password expiration, length, and complexity.

A password with a character set size of 72 and a length of 8 characters has a maximum keyspace of 7*1014. For the example described above, hashes for this entire keyspace could be generated in 12 minutes. Increasing the character set size to 95 only increases the time to 2 hours. However, increasing the length to 12 characters, and keeping the character set size at 72, drastically increases the time needed to generate all the hashes-to over 500 years.

The use of salts also makes cracking more difficult-for example, using 48-bit salting values effectively appends a 48-bit password hash to the original password hash, assuming that the attacker does not have access to the salting values and that the salting values are well-chosen. So a salted password might have the same effective length, and therefore be roughly as time-consuming to crack, as an unsalted password that is several characters longer.

Also, salts typically use the full range of possible values, unlike passwords that have limited character sets, so salts can strengthen the effective password complexity. Policies for password expiration, length, and complexity should take into account the use of salts.

In cases where generating all hashes would take many years, having password expiration would be irrelevant for mitigating cracking, even if most users do not take full advantage of the available character set.

Generally, password expiration periods are not of much help in mitigating cracking because they have such a small effect on the amount of effort an attacker would need to expend, as compared to the effect of other password policy elements. Suppose that an organization reduced its password expiration period from 60 days to 30 days. An attacker would simply need to use twice the hardware resources to compensate for this change.

When password expiration is enabled and it is expected that users will be memorizing their passwords, it is helpful to provide reminders to users that their passwordswill be expiring soon.

Giving users at least a few days or a few logons to prepare for a password change will give them a better opportunity to choose a strong password that they are likely to remember.

Forcing users to change passwords without warning often results in less complex passwords that are easier to remember, or passwords that are stored insecurely (e.g., written on a notepad, stored in a plaintext user file). If setting a new password requires that a user be physically present at the organization's facilities, but the password can be used remotely (i.e., through remote access for telework), then it is generally prudent to notify users one to two weeks before expiration. This makes it more likely that users will have an opportunity to reset the password before teleworking, particularly if they will be traveling for several days.

Password expiration is not effective unless users select different passwords from those previously used. Password history is the retention of one or more previous passwords or password hashes for comparison against new passwords or password hashes. A new password is checked to ensure that it has not been used during the specified history.

The period is usually defined as either a certain number of previous passwords or a period of time. Another password attribute closely related to password history is minimum password age.

The minimum password age is the amount of time that must pass between password changes. To reduce the effort required in remembering passwords, some users will cycle through passwords after expiration until they have exceeded the password history retention buffer and then change their password back to the original. Although enforcing a minimum password age does not prevent this, it is a deterrent.

Some password history mechanisms are also capable of identifying passwords that are not sufficiently different from previous passwords.

When forced to select a new password, some users tend to use variations of old passwords (e.g., changing "password07" to "password08"). This makes it trivial for an attacker who knows the old password to guess or crack the new one quickly. Some password history mechanisms can be configured to reject new passwords that have a certain number of characters in common with previous passwords. Without such a mechanism, it is generally easy for users to append counters to their passwords, such as the "password07" and "password08" examples. This renders password expiration largely ineffective, and may actually cause users to choose weaker passwords than they would have without password expiration.
Password history generally only works on a single authentication mechanism and cannot check history from multiple mechanisms. This allows users to use the same password (and previous passwords) on many systems at once. Users often do this because it reduces the number of passwords that they have to remember, but this increases the risk to the enterprise by allowing an attacker who compromises one password to reuse it to gain access to additional resources.

In addition, administrators will sometimes reuse password between a local user account on a personal workstation and an account that has domain or centralized administrative privileges. This can pose a major risk to the enterprise because the security of centralized password management is generally higher than on individual workstations. An attacker who compromises the workstation and is able to crack the domain administrator password will have significant access to enterprise resources.

There is generally no easy way to detect password reuse across systems, particularly when both internal and external systems are involved. To attempt to reduce the likelihood of password reuse, organizations can have their password management policies prohibit use of the same or closely-related passwords on organizational IT system and external systems.

The password management policy can also explicitly forbid the reuse of centralized (e.g., domain) administrative level credentials with user or local (e.g., local administrator or root) accounts. Proper user training that stresses the importance of proper password management and protection and explains the risks of password reuse should also be implemented. However, without an enforcement mechanism, it is unlikely that policies against reuse will be significantly effective in reducing reuse, given the number of passwords that users typically need to remember.

If an organization believes that a password management system or other source of passwords has been compromised, the organization should act swiftly to mitigate the weaknesses that allowed the compromise, restore the compromised system to a secure state, and require all users to change their passwords immediately. Implementing the enterprise password change will require careful planning and coordination. Procedures should be in place to notify all affected users. This notification should only inform the users of the situation and notify them that their passwords have been reset or need to be changed immediately. Users should be instructed to change their password as they normally would and contact the helpdesk if they need assistance.

If users are allowed to change their passwords, a procedure should be in place to force the change and verify that changes have been made. If passwords are reset to assigned passwords, then there should be procedures in place to communicate the assigned passwords to the users in a secure manner. If the procedures that are in place cause a greatly increased workload on help desk staff, there should be resources available to augment help desk staff to ensure they can effectively handle the password resets.

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