6.3 Security Solutions

Now that you have a solid understanding of the security issues and limitations of Kerberos, let's examine how to work around these limitations and ensure that your Kerberos implementation is as secure as possible.

6.3.1 Requiring Pre-Authentication

First, we will start with pre-authentication. The Microsoft Windows KDC is the only implementation of those covered in this book that requires clients to pre-authenticate by default. In some implementations, a command-line option or flag can be used to require all clients to use pre-authentication. Other implementations require the administrator to explicitly specify which principals need to pre-authenticate before being granted a TGT.

6.3.1.1 MIT

The MIT KDC allows administrators to require the use of pre-authentication on a per-principal basis. Pre-authentication can be enabled for a principal in the MIT KDC through the following kadmin command:

kadmin: modify_principal +requires_preauth principal

6.3.1.2 Heimdal

The Heimdal KDC also allows administrators to require the use of pre-authentication on a per-principal basis. To require pre-authentication for a principal in the Heimdal KDC database, use the following kadmin command:

kadmin> modify principal
Max ticket life [1 day]:
Max renewable life [1 week]:
Principal expiration time [never]:
Password expiration time [never]:
Attributes []:+requires-pre-auth

The Heimdal KDC also allows you to turn off pre-authentication on all principals when starting the KDC, for emergency or testing purposes. The -p or --no-require-preauth switches disable pre-authentication checks for all principals until the KDC restarts.

6.3.1.3 Windows domain controllers

The Windows domain controller KDC service enables pre-authentication for all principals by default. To view the current pre-authentication settings for a principal in the Windows Active Directory, use the following procedure:

You will see a screen similar to the one shown in Figure 6-2.

Figure 6-2. Pre-authentication setting in user properties dialog box

Pre-authentication can be enabled or disabled using the "Do not require Kerberos pre-authentication" checkbox.

6.3.2 Enforcing Secure Passwords

The security of your entire network depends on your users choosing secure passwords. However, experience shows that most users choose quite poor passwords. In one realm that already had password strength-checking in place,^[3] over 2,000 passwords in a Kerberos realm consisting of 25,000 principals were successfully brute-forced during a 2-week period. This experiment was performed with spare CPU cycles available on systems readily available in 1998. A determined attacker with more resources available would have an even easier time. A related experiment was made in 2002 to determine the feasibility of password attacks against the Windows 2000 Kerberos implementation, with similar results.^[4]

^[3] A Real-World Analysis of Kerberos Password Security. Thomas Wu, Stanford University Computer Science Department. May 1998. Available at http://citeseer.nj.nec.com/418833.html.

^[4] Feasibility of attacking Windows 2000 Kerberos Passwords. Frank O'Dwyer. March 2002. Available at http://www.brd.ie/papers/w2kkrb/feasibility_of_w2k_kerberos_attack.htm.

Clearly, these discoveries proved to the researchers it was a cop-out to say that brute-force attacks were outside the scope of the authentication system in the original Kerberos specification. Pre-authentication, as discussed earlier, is a solution that prevents the most egregious of brute force attacks, but another important step to take is to enforce the quality of users' passwords.

Whenever users can choose their own passwords, there is a chance that they will find a way to choose an insecure password, but enforcing some simple heuristics on passwords users choose gives the administrator some guarantee that passwords won't be too simple. Many organizations have policies that outline standards for password strength; these policies usually specify password length as well as the amount of non-alphabetic characters that must be contained in the password. However, the enforcement of these policies is essential to their success. By centralizing authentication, Kerberos also centralizes the enforcement of password policies, making the administrator's life significantly easier.

All of the KDC implementations that we cover support some form of password policy enforcement. We'll take a look at how to configure each one.

6.3.2.1 Heimdal

The Heimdal KDC does not include any password strength-checking code by default. Instead, it only enforces a password minimum of six characters. To perform more stringent password strength checks, Heimdal provides a powerful method to link in an external library in order to verify the strength of user-provided passwords. While this method is powerful, since any external function can be provided to check password strength, it is much harder to set up than the built-in capabilities available in the other KDCs.

In the latest version of the Heimdal KDC, a sample password-check function is available in the source distribution. It uses the freely available cracklib to verify passwords against commonly used passwords and other identifiers. To use this password-checking function, obtain cracklib from http://www.users.dircon.co.uk/~crypto/. Once you've built cracklib, the function is located in lib/kadm5/sample_passwd_check.c. This file must be built into a shared library; the exact command varies depending on your system and compiler, but a sample would be:

gcc -shared  -o sample_passwd_check.so sample_passwd_check.c -lcracklib

Once the shared library is built, add the following lines in your /etc/krb5.conf file to enable the password checking:

[password_quality]
        check_library = path to sample_passwd_check.so
        check_function = check_cracklib

When you restart kpasswdd, the password checking is enabled.

6.3.2.2 MIT

The MIT KDC can evaluate user-supplied passwords based on two metrics: the number of character classes it contains, and its length. The length of a password is obvious, but what is a character class? The MIT KDC defines five different character classes:

• Lowercase letters

• Uppercase letters

• Numbers

• Punctuation

• Other characters

For example, given a password policy with a minimum length of six and minimum of two character classes, the password "MITkdc" would be accepted, while the password "mitkdc" would be rejected. However, a simple password based on a dictionary word such as "Tokens" will pass through fine given a minimum of two character classes. A minimum of three character classes will prevent any dictionary word from being used directly, as a nonalphabetical character is required somewhere in the password.

When specifying the number of character classes required in a password, there is no way to enforce that a number of characters of each class must be included in a password before it is accepted. If the minimum number of character classes is three, then the password is valid as long as there is at least one character from each class in the password.

To enforce certain standards on the strength of passwords used in the MIT KDC, a user policy can be established which can then be applied to a set of principals. To establish or modify an existing policy, the following kadmin commands can be used. More information on these commands can be found in Appendix A.

kadmin: add_policy [-maxlife time] [-minlife time] policy_name
kadmin: modify_policy [-maxlife time] [-minlife time] policy_name

6.3.2.3 Windows domain controllers

The Windows domain controller evaluates user-supplied passwords on two metrics: the length and the complexity of the password. But default, Windows tests a password's complexity by confirming that it:

• Does not contain all or part of the user's account name

• Is at least six characters in length

• Has at least one character from three of the four character classes: lowercase letters, uppercase letters, numbers, and nonalphanumerical symbols

To enable password strength-checking on all accounts in a Windows domain, open the Domain Security Policy Administrative Tool. You will see a screen similar to the one in Figure 6-3. Open Security Settings Account Policies Password Policy. Inside you will find two settings: "Minimum password length" and "Passwords must meet complexity requirements". Enabling the complexity requirements will enable the checks outlined above.

Figure 6-3. Windows Domain Security Policy

6.3.3 Enforcing Password Lifetimes and History

In addition to policies on password strength, many organizations also specify a maximum lifetime for user passwords after which the user must change to a new password. Most Kerberos KDC implementations can enforce a maximum and minimum lifetime for user passwords, as well as a password history to ensure that users do not simply reuse previous passwords to evade the mandatory password change.

While it may be tempting to specify a very short maximum lifetime for user passwords to prevent brute-force attacks and reduce the effectiveness of a stolen password, it is important to realize that mandatory password change policies represent a quality versus quantity trade-off. As the frequency of password changes goes up, the quality of each password chosen goes down, or else the user will resort to writing her password down.

In addition, most of the KDCs covered in this book have a facility to remember previous passwords that the user has chosen, to prevent the user from flip-flopping back and forth between a few passwords.

6.3.3.1 MIT

To enforce mandatory password lifetimes in the MIT KDC, a user policy can be established which then can be applied to a set of principals, or lifetimes can be set on a per-principal basis. Let's first take a look at how to set password lifetimes on a policy:

kadmin: modify_policy [-maxlife time] [-minlife time] [-history num] policy_name
kadmin: add_policy [-maxlife time] [-minlife time] [-history num] policy_name

In each command, the optional maxlife parameter specifies the maximum lifetime of the user passwords subject to the policy policy_name. Similarly, the optional minlife parameter specifies the minimum lifetime for user passwords subject to the policy.

In addition, the number of historical passwords kept for user principals subject to this policy can be specified with the history parameter. The only argument that the history parameter takes is the number of historical passwords to check against when changing passwords.

If you already have a policy established (for example if you've already set up a policy from the last section), then you can use the first command to modify your existing policy to add a mandatory minimum and maximum lifetime and password history.

6.3.3.2 Heimdal

The Heimdal KDC only includes the ability to expire a principal's password at a given time. Once the password expires, the user is prompted to change it, and the new password is now active. However, the password expiration is not recurring; that is, if you set a principal's password to expire in 30 day's time, once the password expires, it will not automatically set the user's password to expire 30 days from that day. Instead, the administrator must set the password to expire again.

To set a password expiration date on a principal, use the following kadmin command:

kadmin> mod jgarman
Max ticket life [1 day]:
Max renewable life [1 week]:
Principal expiration time [never]:
Password expiration time [never]:2002-08-05
Attributes [requires-pre-auth]:

This sets the jgarman principal's password to expire on Aug 5, 2002.

6.3.3.3 Windows domain controllers

The Windows domain controller has the ability to set both maximum and minimum password lifetimes, as well as establish a password history to prevent reuse of previous passwords. The administrative interface to adjust these parameters is located in the Domain Security Policy. Open Security Settings Account Policies Password Policy. The window shown in Figure 6-3 will appear. Inside you will find three settings: "Minimum password age", "Maximum password age", and "Enforce password history".