Computer Password | Guessing and Cracking

There are several forms of guessing. In a brute force attack, the attacker attempts to guess the password using all possible combinations of characters from a given character set and for passwords up to a given length.

This method is likely to take an extensive amount of time if there are many combinations to be tested. In a dictionary attack, the attacker attempts to guess the password using a list of possible passwords.

The list may contain numbers, letters, and symbols, but is not an exhaustive list of all possible passwords or combinations that could create a password. In a hybrid attack, the attacker uses a dictionary that contains possible passwords and then uses variations through brute force methods of the original passwords in the dictionary to create new potential passwords.

Since the attacker is adding characters-and in some cases replacing characters based on a rule set-in a controlled manner, the attack is more exhaustive than a dictionary attack but takes less time than a brute force attack. Another form of guessing attack is to search the victim's information for possible password content, such as family member names or birthdates.

Guessing attacks can be mitigated rather easily by using a combination of two methods. First, ensure that passwords are sufficiently complex so that attackers cannot readily guess them. It is particularly important to change all default OS and application passwords; lists of default accounts and passwords are widely available to attackers.

Organizations should also ensure that other trivial passwords cannot be set, such as the username or person's name, "password", the organization's name, simple keyboard patterns (e.g., "qwerty", "1234!@#$"), dates (e.g., "03011970"), dictionary words, and names of people and places. Most password mechanisms have the ability to prevent the use of such passwords.

The second method recommended for mitigating guessing attacks is to configure OS and application password authentication mechanisms to limit the frequency of authentication attempts. Examples of how this can be accomplished include the following:

-Lock out a user account after a number of consecutive failed authentication attempts (often performed within a particular time period, such as the past hour). For example, after a user has failed to provide the correct password 50 times in a row, ignore all additional authentication attempts to the user account for 15 minutes. Locking out an account after only a few failed attempts has a significant impact on legitimate users and tends to cause them to choose simpler passwords or store their passwords insecurely, thus weakening security.

-Have a fixed or exponentially increasing delay after each failed authentication attempt. After the first failure, for example, there could be a five-second delay; after the second failure, a 10-second delay; after the third failure, a 20-second delay, and so on.

Guessing is made easier by password mechanisms that inadvertently provide information about passwords to attackers. For example, information might be available when a password is entered, such as an input field that only accepts a maximum of eight characters, says that the username does or does not exist, or that has its "OK" button grayed out until the minimum required number of characters has been entered. This information is very helpful to authorized users when they are creating new passwords, but when this information is provided during authentication, it may benefit attackers more than legitimate users.

A special case of password guessing is the use of default passwords for password resets, such as when accounts are first created. A password reset is often accomplished by setting a one-time password (OTP), which is a password that is set to expire immediately, and thus can only be used to gain access to a system one time.

An example of how OTPs are used is a help desk staff member creating a new account. The help desk member sets an OTP for an account and provides the OTP to the user. The user may log in with the OTP once, at which point the OTP expires and the user is required to set a new password.

Randomly generated or arbitrarily chosen OTPs, not default or patterned passwords , should be used during account creation and password reset processes.

This ensures that if the user does not promptly change the assigned password, that the password will not be easily guessable. In some automated procedures, using a random OTP can be omitted because the user will set a new password immediately after verifying his or her identity to the system. Also, if a help desk agent or other security administrator walks the user through setting a new password in a timely fashion, a random OTP may not be necessary.

Cracking involves attempting to discover a character string that will produce the same encrypted hash as the target password.

The discovered string may be the actual password or another password that happens to produce the same hash. If the hash algorithm is weak, cracking may be much easier. Hash functions should be one-way, otherwise attackers that can access hashes may be able to identify passwords from them and successfully authenticate.

Another example of a hash algorithm weakness is that some algorithms do not use salting. Salting is the inclusion of a random value in the password hashing process that greatly decreases the likelihood of identical passwords returning the same hash. If two users choose the same password, salting can make it highly unlikely that their hashes are the same.

Attackers using cracking techniques often employ rainbow tables, which are lookup tables that contain pre-computed password hashes. These tables allow an attacker to attempt to crack a password with minimal time on the victim system and without constantly having to regenerate hashes if the attacker is attempting to crack multiple accounts.

For instance, the attacker generates or acquires a rainbow table that contains every permutation for a given character set up to a certain length of characters. The attacker then uses the table against two separate password hash files, but does not have to generate the permutations twice since they were previously created.

This allows the attacker to avoid re-computation and to perform cracking more quickly by traversing the lookup table versus generating the hashes on-the-fly.

There are some issues with using rainbow tables. They can take large amounts of storage and can take a long time to create (although the latter issue may not be important if the attacker can acquire copies of existing tables or reuse tables that the attacker previously created).

Also, the use of rainbow tables can be hampered by using salting. Rainbow tables will not produce the right results if they do not take salting into account, which dramatically increases the amount of space that the tables require; larger salts effectively make the use of rainbow tables infeasible.

Many OSs, such as Mac OS X and other Unix-based OSs, often implement salted password hashing mechanisms to reduce the effectiveness of password cracking.

Another technique that helps mitigate the use of rainbow tables is called stretching. Stretching involves hashing each password and its salt thousands of times. This makes the creation of the rainbow tables correspondingly more time-consuming, while having little effect on the amount of effort needed by the organization's systems to verify password authentication attempts.

All forms of cracking can be mitigated by making passwords strong, using one-way password hash algorithms, and protecting the confidentiality of password hashes. Changing passwords periodically also slightly reduces the risk posed by cracking.