Securing Password-Based Authentication
Passwords are by far the most popular way of confirming your identity to a web application. This reason alone warrants a more in-depth discussion on how hackers will attempt to attack a password-based authentication system and how you can successfully defend against them.
Attacks Against Passwords
Because the use of passwords is pervasive as an authentication factor in web applications, they are also a very popular target of attackers. All attacks against passwords essentially boil down to repeatedly guessing at the password in an attempt to determine the plaintext value of the password. When attempting to guess a password, you can attempt it either against the live system (online) or against the hashed or encrypted password values (offline). Common attack variations include:
Dictionary attack
Brute-force attack
Precomputed dictionary attack
Rubber-hose attack
These attacks can be performed online against live web applications, or they can be performed offline against the hashed (or encrypted) password values that an attacker has acquired. With live web applications, the credentials are repeatedly submitted to the application as seen in Figure 3-10. Each guess requires time for the credentials to be submitted, processed by the application, and the response to be returned. As a result, it’s considerably slower than an offline attack.
Figure 3-10 Online attacks are slow.
Offline attacks, as shown in Figure 3-11, have the advantage of speed but require that the attacker already has the hashed (or encrypted) password value. This approach works by taking a guess value, hashing it using the same hashing algorithm, and then comparing the result against the known hashed password value. If the two values match, then you know that your guess was correct. Because the hashing and comparison can be done incredibly fast (http://openwall.info/wiki/john/benchmarks), it’s possible to test from tens of thousands to hundreds of thousands of password guesses per second depending on the speed of your system. Additionally, offline attacks are stealthier because they do not impact the performance of the online system by making repeated incorrect logon attempts. Once the attacker successfully guesses the password, he or she can log on to the application without triggering any counter-defenses such as locking an account after three failed logon attempts. Consequently, protecting the hashed password store is of paramount importance.
Figure 3-11 Offline attacks are much faster.
Now let’s look at each of the attack variations and how they apply in online and offline situations.
Dictionary Attack
A dictionary attack is based on the premise that users have a predilection for selecting passwords based on real words that can be found in dictionaries. The most likely candidate words can be collected in a list that is referred to as a “dictionary.” In some cases, real dictionaries may be employed, and creating permutations, such as appending a digit or special character at the end of each word, may be done as well. With a dictionary in hand, an attacker will successively attempt each password until they have successfully guessed the password or the list is exhausted.
In online situations, it is uncommon for full dictionaries or exhaustive attacks to be used because of the timing limitation; instead, a targeted dictionary is employed. However, offline attacks can be far more comprehensive, and they commonly utilize multiple dictionaries with several languages in addition to generating their permutations. Offline attacks usually begin with one of these massive dictionaries to locate any weak passwords before moving on to using brute-force attacks for the harder-to-crack passwords.
Brute-Force Attack
A brute-force attack is also referred to as an exhaustive key search, and in theory involves attempting every single possible key. In reality, limits are usually placed on a brute-force attack based on length and character set (for example, alphabet, digits, whitespace, special characters). The brute-force approach is rarely, if ever, used against online web authentication systems due to speed constraints. It is frequently used in offline attacks against hashed password values.
Precomputed Dictionary Attack
One downside of dictionary attacks and brute-force attacks is that every time you want to crack a password, you must rehash all the dictionary or brute-force values. Naturally, this is a big waste of time. What if you could pre-hash all the values in a dictionary or pre-hash all the possible permutations of characters within a certain length, and then store those values to disk? Then if you wanted to crack a password, you would only need to look up the password hash value in your stored system instead of trying to compute its equivalent. In essence, you’re trading time for disk space, and this method of cracking passwords is called a precomputed dictionary attack. Because of the large space requirements, a variation on the time-space tradeoff was achieved with the use of rainbow tables (http://en.wikipedia.org/wiki/Rainbow_table). Rainbow tables are built on the time-space tradeoff approach but offer reduced storage requirements at the expensive of longer lookup times. Popular implementations of this approach include Ophcrack, which works against Windows passwords, and RainbowCrack, which works against a variety of hashing algorithms including LM, MD5, SHA-1, and more. One key defense against a precomputation attack involves the use of a salt, which increases the potential key space that must be hashed. We’ll cover the use of a salt in more detail later.
Popular tools to perform dictionary and brute-force attacks include John the Ripper, Hydra, Web Slayer, and Cain & Abel. Running these tools against your own systems can help you determine the strength of your own passwords.
Rubber-Hose Attack
A “rubber-hose” attack refers to instances in which an intruder uses any sort of physical coercion to extract the value of the password from an individual. Like cranberry sauce at Thanksgiving, the traditional tool is a “rubber hose” but may be replaced by another “implement,” even a harmless piece of chocolate (as a report from the BBC revealed, a high percentage of computer users will reveal passwords for a bar of chocolate. See http://news.bbc.co.uk/2/hi/technology/3639679.stm).
The Importance of Password Complexity
Have you ever wondered why your password must be composed of a minimum of eight characters using upper and lowercase alphabet, digits, and special characters? It’s because we know that attacks like brute-forcing will eventually attempt every possible password, so we can assume that any password will eventually be cracked given enough time (the exception to this is the proper use of one-time pads, which is unbreakable). Our goal is to make it harder for attackers to guess our password, and we do that by increasing the complexity requirements, which in turn makes it more difficult to guess its value.
By “difficult,” what we really mean is making it take as long as possible to exhaustively search the potential key space (also known as “all passwords have been guessed”). If we make our key space larger, the time required to search all possibilities will be longer. Thus, to reduce the likelihood of our password being guessed within a reasonable amount of time, we want to make our key space larger.
We can increase the size of our key space by increasing the minimum length required by our passwords and by increasing the number of possible characters that can be used in our passwords. For example, it would take longer to guess all the possible ten-digit passwords (ten billion possibilities) than it would to guess all the possible four-digit passwords (ten thousand possibilities). Along the same lines, we can increase the character set. It would take longer to guess all the 10-element alphanumeric passwords (8.39 × 1017 combinations) than it would to guess only the 10-digit passwords (1.0 × 1011 combinations).
We can make things even more difficult by regularly changing our passwords as well. Let’s say we have a password that was created using strong complexity requirements, and it would take an attacker 100 days to attempt every single possible password that could be generated using the strong complexity requirements. Let’s say that we set our password and at the very same moment an attacker began to guess it by brute force. We know that we have at most 100 days before they would eventually guess the password, so if we changed our password at the 50-day mark, then the attacker would only be able to search 50 percent of the possible key space. Thus, there would be a 50 percent chance that an attacker could guess our password before we changed it. If we changed our password every 10 days, then there would only be a 10 percent chance of it being guessed. The lesson here is that changing your password on a more regular basis allows you to reduce the likelihood of an attacker guessing its value. One additional benefit of password rotation is that it forces you to change any passwords that may have previously been compromised without your knowledge.
IMHO
Password rotation frequency is an important yet often misunderstood topic. Most best practices call for a password rotation every 90 days. I don’t think you need to change your password every 90 days. If you’re smart about it, you may even be able to hold off as long as 180 days or more. Why? Because the primary reason for rotation passwords is to force the attacker to restart their brute-force attempt.
Looking back on our previous example, if it takes an attacker 100 days to guess our key space and we rotate our passwords every 10 days, then there’s a 10 percent chance of the password being guessed before the password is rotated out, and the attacker must restart their brute-force attack. If we’re comfortable with changing the password every 10 days, then what we’re saying is that we’re willing to accept a 10 percent level of risk. Along these lines, we should then be comfortable changing our password every 90 days if it takes 900 days to guess the password. Taking it a step further, if we can create a password complex enough that it requires 1800 days to exhaust the key space, then we can reduce the rotation frequency to 180 days. This has been represented in Figure 3-12.
Figure 3-12 Equivalent acceptable levels of risk
Password Best Practices
In addition to password complexity, there are a number of best practices that you should follow to improve the security of a password-based authentication system.
Require Minimum Password Length
Minimum password length is the smallest number of characters that a password should be composed of. Recommendations vary widely, so it’s difficult to direct you to any consistent or official guidance on password complexity. Instead, we’ve synthesized the best recommendations around password complexity, and here’s our contribution:
You notice that we recommend at least 12 characters for a minimum (http://www.gtri.gatech.edu/casestudy/Teraflop-Troubles-Power-Graphics-Processing-Units-GPUs-Password-Security-System), while many web applications stop at 8 characters. The reason for this is that the length of a password contributes more to its security than the possible characters.
Think of it this way. The number of possible permutations of a set of X characters with a length of Y is calculated with X˄Y. Let’s say that you only have alphabet characters and a minimum length of 12. In this case, you would have 26˄12 or 9.54 × 1016. Now let’s double the number of possible characters but halve the length, so we have 52˄6 or 1.98 × 1010. The reason is that the exponent has a much greater effect on the number of permutations than the base value. One of the most lucid explanations of this concept that I’ve ever run across can be found in this comic (http://www.xkcd.com/936/).
Enforce Minimum Password Complexity
A complex password is one of your greatest defenses against dictionary and brute-force attacks. Here again, it’s difficult to find a consistent or official recommendation. Our recommendation (http://www.microsoft.com/canada/smallbiz/sgc/articles/select_sec_passwords.mspx) is that passwords include at a minimum at least one character from four of the following categories. Stronger passwords should contain at least one character from three of the categories and at least two from one of the categories. Passwords may also include Unicode characters where supported.
Rotate Passwords
We discussed the premise of password rotation frequency earlier. It’s worth stating that the general industry best practice is to rotate passwords at least every 90 days. On the flip side, you also want to enforce a minimum password age. This is to prevent users from resetting their passwords several times in one day and flushing their password history. This would allow them to bypass the No Password Reuse practice.
Require Password Uniqueness
When a user is required to rotate their password, they should not be able to reuse one of the passwords that they’ve recently used. Usually, a password history is kept of a user’s last eight passwords, and the application does a check to make sure that they aren’t reusing one of those last. You can vary the size of the password history depending on your requirements.
Password Cannot Equal Username
One of the first things that an attacker will check for is whether the password of an account is equal to its username. Under no circumstances should a password be allowed to equal its username.
Allow Accounts to Be Disabled
When an employee takes an extended leave, or if a user will not be using an account for a long period of time, it’s useful to be able to disable accounts to reduce the potential attack surface against the authentication system. In addition, disabling accounts allows you fine-grained control to limit the impact if a user’s password has been compromised. Keep in mind that disabling an account does not mean that it’s been deleted, so you do retain the information associated with the account.
Properly Store Passwords
The best recommendation when storing passwords is not to store them at all unless absolutely necessary. However, when you must store passwords, we recommend using a strong hashing algorithm with a salt and using multiple rounds.
Don’t Store in Plaintext It’s fairly obvious that passwords shouldn’t be stored in plaintext lest an attacker who is able to perform an attack such as SQL injection (covered in Chapter 7) compromise your entire user base in one fell swoop. I say fairly because I still see it happen from time to time.
Don’t Encrypt Perhaps less evident is the recommendation that passwords shouldn’t be encrypted either. What we mean is that passwords should not be secured using encryption, which implies that a key must exist somewhere that was used to encrypt the data. This poses two problems. One, if you encrypt data, then it stands to reason that you can decrypt the data if you have the key. Two, if you have a key, then you need to protect it, which introduces a whole different set of issues. The chain of key protection is a subject beyond the scope of this section, but suffice it to say that it’s a complex matter. A very good reason notwithstanding, our passwords should never need to be decrypted into their plaintext equivalents.
Use a Strong Hash The recommendation for passwords is to use a hashing algorithm to perform a one-way transformation on the content. The hashed password value is then stored in a database record that’s tied to a specific username. Whenever a user authenticates to the web application, the password is hashed using the same algorithm and then compared to the stored value. If the hashed values match, then we know that the passwords match. Strong hashing algorithms for passwords include SHA-256, and even better, SHA-512. Weaknesses in the MD5 and SHA-1 algorithms have resulted in these algorithms being deprecated.
Use a Salt In addition to the hashing, we recommend using a random salt value with each password to increase the security of the password. The reason that we recommend using a salt value is two-fold. First, using a salt value makes a precomputed dictionary attack much more difficult because of the additional number tables that must be computed to effectively perform a lookup. Even using a 16-bit hash value results in an increase of 65,536 times in the effort required to generate a lookup table. Second, if two people happen to choose the same passwords, say “Virus Maelstrom”, then their passwords would hash to the same value, and it would be immediately evident to an attacker who has obtained and is trying to crack the hashes. Using a salt results in a different hash value being stored for each password even if they are equivalent in their plaintext forms. This makes it harder for the attacker to guess. Current best practice suggests using at least 64 bits for the salt value.
Tip
If a salt value is used to create the original hash of the password, then to perform subsequent comparisons, the original salt value must be stored somewhere. Commonly the salt value is prepended or appended to the stored password hash. Because the length of the salt is a known value, it’s simple for the password verification algorithm to pull it off the front or back of the stored entry.
Multiple Rounds of Hashing Using multiple rounds of hashing means that for each password being stored, you apply the hashing algorithm over and over. The output of the hashing function becomes the input to the hashing function, which produces an output that becomes an input, and so forth.
The reason for running multiple rounds of hashing is to make it more difficult for attackers to perform both brute-force and time-space tradeoff attacks. Multiple rounds of hashing directly multiply the amount of processing power required for the attacks. It’s not overly burdensome for you to use 10,000 rounds, the current industry standard, of hashing per password when storing or performing a comparison, because usually you’ll get a few passwords at a time. However, an attacker is trying to perform a comparison between the entire key space, so the effect of multiple hashing rounds is magnified 10,000 times against the entire key space as opposed to a few passwords. Standard mechanisms such as PBKDF (Password Based Key Derivation Function) and the latest incarnation, PBKDF2 (http://tools.ietf.org/html/rfc2898), assist in performing the hashing and multiple rounds of iteration. Consider using an implantation of a PBKDF2 function to secure your passwords.