Password Policy for Directories

Introduction

Authentication by use of a username & password is widely used, and efficiently managed organizations will normally apply a number of controls on passwords. These controls, collectively referred to as “password “might include:

• Passwords must be at least six characters long.
• Passwords must be changed at least once every six months.
• Users must change passwords after an administrator reset.

In situations where applications share common username/password it is often desirable to manage them in a single location. This is convenient for the user and generally gives better security by keeping the authentication in one place.

Directories are a good location for handling the sharing of password based authentication, as:

• They are a natural location for identity and account information.
• They allow for a common password policy to be applied across all applications.
• LDAP (Lightweight directory Access Protocol) Directories provide good support for password based authentication.
• Use of multiple replicated servers provides high resilience and good performance scaling.

Isode’s password policy and associated control of password hashing is applied to a directory server, and may be different for different servers.

Control of Password Hashing

There are two basic approaches to storing passwords in a directory.

1. Store a cryptographic hash of the password. The password cannot be determined from the hash, which is a one way mechanism. However, the hash can be used to validate the password. The advantage of storing hashed passwords in the directory is that, if the hashed passwords are exposed, they are not directly usable to authenticate to the directory (or directory application). The disadvantage of storing hashed passwords is that they hinder use of stronger password-based authentication mechanisms, and rely on non-standard extensions to the directory service.
2. Store the password. There are certain authentication mechanisms, such as DIGEST MD5, that work without transferring a password in the clear. These mechanisms require access to the password, and will not work on a hash.

It can be seen that there is a security trade-off to be made. Part of the password policy is the choice of how passwords are stored in the directory. Isode offers:

1. Store password in the clear.
2. Store password hashed. M-Vault supports the following hash algorithms:

• MD5 (Message Digest 5)
• SHA-1 (Secure Hash Algorithm 1)
• SHA-256 (Secure Hash Algorithm 2 – 256 bits).
• Unix (traditional) Crypt(3).

These are supported direct and with “salted” variants (apart from d, which is always salted). Salting is a mechanism that increases

If the configured set of hash algorithms changes, the data stored in the directory will be updated when the user binds to the directory (i.e., the password storage is automatically updated when the password is checked).

Password Quality

The password policy is used to control the “quality” of the password:

• Password minimum length.
• Password must contain characters from three of the following four sets
  • Uppercase letters (A-Z).
  • Lowercase letters (a-z)
  • Digits (0-9)
  • Other character (e.g., punctuation).

This policy will be enforced whenever the password is changed.

Password Ageing

This password policy is used to ensure that passwords are changed regularly. The control is specified simply by specifying maximum password age. The user may be warned on authentication when the password will expire, and after the password has expired it will cease to work.

Password History

Password history is a mechanism to prevent password re-use, which can be a security risk. Hashes of previously used passwords are stored so that the directory server can ensure that a new password has not been previously used. Old passwords are stored for a time specified by the password policy, and after this time a password may be re-used. There is no limit on the length of password history stored, so a user cannot revert to a “preferred password” simply by making lots of password changes.

Account Disable

There is an underlying mechanism to specify the state of an account, which can be active or disabled. This allows an operator to disable an account and prevent login for whatever reason. The operator can also describe (in a directory attribute) the reason for the account being disabled. This mechanism applies to other login mechanisms, and in particular to strong authentication. So this capability is really access policy, rather than password policy.

Force Password Reset

The user can be required to change their password after the administrator has set their password. The administrator can also force a user to change their password (without first setting it). When a password change is required, the user will be able to authenticate with their old password solely for the purposes of changing their password, as described in the next section.

Grace Login

When a user password has expired, or the user is required to change their password, the user is allowed a limited number of logins in order to change the password. When a password change is required, the user will not be allowed to perform any other operation. This mechanism is called “grace login”. If the user exhausts all of the allowed grace logins, their account will be locked. Administrator action is required to unlock the account. If the server is not configured to offer

Provide Old Password

With standard LDAP, it is possible to authenticate a connection (by password or strong authentication) and subsequently set a new password. This has a security risks, as an authenticated session may be abused. The “provide old password” password policy requires that the old password is provided at the same time as the new one. The user will see this as a screen that asks for old password at the same time as

DSA Generated Passwords

Rather than allow the user to select (potentially insecure) passwords, passwords can be chosen by the directory. The user can reject the choice and ask for another one. M-Vault generates 8 character passwords conforming to the character set password quality.

Repeated Login (Password Guessing)

M-Vault provides two mechanisms to prevent attacks where repeated logins are used in an attempt to guess passwords. The primary mechanism is to insert a delay before returning information on authentication failure, and increasing this delay for repeated failed authentications on the same connection. This approach slows authentication, and makes brute force attacks impractical.

A second approach sets the number of incorrect password authentications that are allowed by a directory server. If this number is exceeded, the account is disabled for a configurable temporary period. Note that this policy is implemented on a “per server” basis, to avoid synchronization and performance difficulties of sharing failed authentication information between servers. This means that in a load balanced situation, the limit seen by the user may increase, where authentication is handled by different servers. Although this approach appears stronger, it introduces a denial of service attack, where an attacker can lock someone out.

LDAP Protocol Support

All the password policy capabilities apply (with the exception of generated passwords) to both DAP and LDAP (without extension). In addition:

1. There is a special “Change Password” operation. The “provide old password” policy requires this operation to be used.
2. The core LDAP specification makes the password visible as the userPassword attribute. This can be retained as a visible attribute, or passwords can be hidden and only accessed by authentication operations and Change Password.
3. In order to communicate information to the user (e.g., that a password is too short or a password expiry warning) there is an LDAP extension (known as an LDAP control) that enables this additional information to be communicated.

Password Policy Standardization

There have been various attempts to standardize password policy. There is a draft specification “Password Policy for LDAP Directories” that has been used as the basis for a number of implementations. Isode’s

There is clear benefit to having a standardized approach to password policy, and Isode staff will be working with LDAP (Internet) and X.500 (ITU-T/ISO) standards groups on this. Once standards are agreed, Isode’s implementation will be changed as needed.

Managing Password Policy

The policies described in this document are all represented within the directory. This means that password policy can be controlled by a directory client. The following screenshot shows how Isode’s M-Vault console (MVC) product can be used to configure password policy for an M-Vault server.

The End User Experience

Password policy has limited impact on the end user. There will be two effects in normal use:

1. When password is changed, the password quality and password history controls will constrain choice of new password.
2. If password ageing is used, users will see warnings of password expiry when they log in.

Operator Support

Operator tools to handle passwords after account creation need the ability to:

• Disable accounts.
• Force password reset.
• Set password, and force immediate change.

Isode plans to provide Web based operator tools that are password policy aware.

Self Service Password Reset

Some organizations provide mechanisms to support “self service” password reset. The capabilities provided here make this straightforward. This would be implemented by a trusted (Web) application that interacts

1. Send information to the email account of the user.
2. Ask questions to the user to determine that it is the user.

Email address, and question/answer information can be stored in the directory, and so it is straightforward to build such an application over the underlying directory with password policy support.

Support System Components that must Read Passwords

Many applications support authentication by validating against the directory, typically using SASL (Simple Authentication and Security Layer) validation against the directory. In particular, Web applications will normally work like this. In this scenario, authentication will be handled by the directory that can enforce password policy.

Some applications need to authenticate directly. The most common situation is where an application is using an authentication mechanism that does not pass clear text passwords, such as DIGEST MD5. Here the application needs the clear password, and needs to work by reading this from the directory as a trusted application. It is desirable that this application enforces the same password policy as the one configured in the directory, but to avoid duplicating password policy capabilities in the application.

Isode’s planned approach here is provide password policy information to the SASL component that reads passwords, so that password policy can be correctly enforced for the application. In particular:

• Ensure that the account is active.
• Provide information on password expiry.
• Provide information on dealing with failed authorization and repeated login attempts.

Conclusions

Password Policy provides important management capabilities for organizations deploying systems using password based authentication. It enables used of “single password” in the directory for all applications, and a single application independent password policy.