Kerberos Password Policies Made Easy

Password policies are typically part of an organization's larger security policy and dictate items such as:

• Minimum password length
  
• Number of character classes
• Which character classes are used
• Use of dictionary words
  
• Minimum password age
• Maximum password age
• Number of invalid password attempts
• Lockout and duration of lockout

The last two items of the list actually apply to an internal security control known as a clipping level. A clipping level (such as the maximum number of invalid password attempts before an account is locked out) greatly reduces the feasibility of a brute force password attack against a given authentication source because it increases the risk of detection by the user who owns the account and greatly reduces the number of password attempts that can occur during a given period of time.

Here is an example of how clipping levels reduce the number of password attempts in a given period of time. Say the organization only allows 3 invalid password attempts and locks a principal from authenticating for 10 minutes. Assume the attacker can carry out 1000 authentication attempts per minute without the clipping level. To achieve the same 1000 authentication attempts with the clipping level, the account would be locked out for around 3330 minutes (~2.31 days). This results in an average rate 0f 0.3 authentications per minute. As the length and complexity of a password increase, the average number of attempts increases significantly to the point that an attacker is effectively forced to use other methods to obtain a password (such as social engineering or key logging). Assuming that the correct preventative and detective controls are in place, an attacker will be forced to try to find another way to compromise a system/network.

The two main Kerberos distributions in use, MIT Kerberos V and Microsoft Active Directory, both allow password complexity and clipping levels to be set by policy. Microsoft Active Directory password policies can be set by default in the Default Domain Controllers Group Policy Object (GPO) and can be set in the Local Security Policy administrative tool for workgroup (non-domain) systems. In Active Directory, the default GPO precedence does not allow password policies to be set in the Default Domain Policy GPO and policies defined in the Default Domain Policy GPO will be overwritten.

For MIT Kerberos V KDCs, the password policies are stored as part of the database (and are propagated via slave KDC propagation) and are associated with principals. Creating a policy is relatively straightforward using the add_policy command in kadmin/kadmin.local.

For older versions (1.6.3 in this example) of MIT Kerb, no automatic unlock feature was implemented:

kadmin.local:  add_policy
usage; add_policy [options] policy
        options are:
                [-maxlife time] [-minlife time] [-minlength length]
                [-minclasses number] [-history number]

For newer versions (1.10 in this example), the feature is implemented as part of the password policy:

kadmin.local:  addpol
usage; add_policy [options] policy
        options are:
                [-maxlife time] [-minlife time] [-minlength length]
                [-minclasses number] [-history number]
                [-maxfailure number] [-failurecountinterval time]
                [-lockoutduration time]

By default, no policy is applied when a principal is created:

kadmin.local:  ank burrm
WARNING: no policy specified for burrm@MIKESBLOG.LAN; defaulting to no policy
Enter password for principal "burrm@MIKESBLOG.LAN":
Re-enter password for principal "burrm@MIKESBLOG.LAN":
Principal "burrm@MIKESBLOG.LAN" created.

If you create a policy named "default" then it will be applied to all new principals (but not applied to existing ones):

kadmin.local:  addpol -minlength 12 -minclasses 2 default
kadmin.local:  add_principal burrm2 
NOTICE: no policy specified for burrm2@MIKESBLOG.LAN; assigning "default"
Enter password for principal "burrm2@MIKESBLOG.LAN":
Re-enter password for principal "burrm2@MIKESBLOG.LAN":
Principal "burrm2@MIKESBLOG.LAN" created.
kadmin.local:  getprinc burrm2
Principal: burrm2@MIKESBLOG.LAN
Expiration date: [never]
Last password change: Thu Mar 08 14:24:03 MST 2012
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Thu Mar 08 14:24:03 MST 2012 (burrm/admin@MIKESBLOG.LAN)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: default

The principal created before is not affected by the creation of the new default policy:

kadmin.local:  getprinc burrm
Principal: burrm@MIKESBLOG.LAN
Expiration date: [never]
Last password change: Thu Mar 08 14:09:25 MST 2012
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Thu Mar 08 14:09:25 MST 2012 (burrm/admin@MIKESBLOG.LAN)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]

A dictionary file can be used globally and is specified by the dict_file option in the [realms] section of the kdc.conf file. It should be noted that if a principal is created with a policy, the password has to conform to the policy. Also, if a principal  To set a weaker password (sometimes used by tier 1 staff when a user forgets his/her password), the policy must be cleared with the modprinc -clearpolicy command before a weak temporary password can be set. A way for a tier 1 help desk technician to reset a password could be the following:

kadmin:  modprinc -clearpolicy burrm2
Principal "burrm2@MIKESBLOG.LAN" modified.
kadmin:  cpw -pw "temp123" burrm2
Password for "burrm2@MIKESBLOG.LAN" changed.
kadmin:  modprinc -policy default -pwexpire yesterday burrm2
Principal "burrm2@MIKESBLOG.LAN" modified.

This clears the policy temporarily, changes the password to something easily communicated, then reinstates the policy and forces the user to change password at next use. There is a high probability that this should just be incorporated into a helpdesk script because it may be difficult for tier 1 staff to remember and properly execute all of the steps. Additionally the steps may be undesirable because the tier 1 staff would need somewhat elevated permissions with kadmin to make the changes. If policies are assigned, users/admins will likely encounter the following errors when changing passwords:

Not long enough:

kadmin.local:  cpw burrm2
Enter password for principal "burrm2":
Re-enter password for principal "burrm2":
change_password: Password is too short while changing password for "burrm2@MIKESBLOG.LAN".

Not complex enough:

kadmin.local:  cpw burrm2
Enter password for principal "burrm2":
Re-enter password for principal "burrm2":
change_password: Password does not contain enough character classes while changing password for "burrm2@MIKESBLOG.LAN".

Previously used:

kadmin.local:  cpw burrm2
Enter password for principal "burrm2":
Re-enter password for principal "burrm2":
change_password: Cannot reuse password while changing password for "burrm2@MIKESBLOG.LAN".

Password policies are pretty simple to set up and serve as a valuable tool to help reduce the risk of compromise due to brute force attacks. Use them wisely, because users will tend to do insecure things with overly complex passwords and passwords that need to be changed frequently including writing them on post-it notes, whiteboards, and pads of paper. Some people may tape them to a monitor or place them in a drawer or under a keyboard. In many ways, an overly harsh password policy is worse than not having a password policy and actually serves to hurt organizational information security instead of helping it.

See Also,
Deploying a Kerberos KDC in Ubuntu 11.10 or Fedora 15