Password Policy Enforcement
When users select a new password with P-Synch® -- either using the web GUI or by changing their password natively on a system that has been configured to trigger transparent synchronization, P-Synch applies a site-defined set of password quality rules. Users are not allowed to select passwords that violate this policy.
The policy engine supports over 50 types of rules, including an unlimited-length history, word and permutation checks against various dictionaries and checks against the user ID and its permutations. Regular expression matching is also supported so that the customer can define its own rules if they are not supported in P-Synch.
With the web GUI, password policy rules are displayed to the user on the screen where users are prompted to select a new password. Rule violations, if any, are detailed on the subsequent screen.
With transparent synchronization, password policy rules are not generally displayed, in order to leave the native password change mechanism untouched. Password policy violations are communicated to the user with various mechanisms, including win-popup messages, e-mail and display to the user's terminal session on Unix and OS/390 systems.
Learn more about the password strength rules that P-Synch can enforce.
A Global Policy
P-Synch is normally configured to support a single, global password policy, to ensure that all new passwords will be acceptable to every system. This setup provides the most clear and understandable experience to users. P-Synch is configured such that it will never accept or attempt to propagate a password that will not meet this global password policy.
For instance, in the case of an organization that has both Windows Active Directory (AD) and OS/390 passwords, where users may enter very long passwords on AD but only 8 characters on the mainframe, P-Synch can require that passwords be exactly 8 characters long. Alternately, P-Synch can support longer passwords, but truncate them when it updates the mainframe. (Users generally prefer the preset length rule, as it is easier to understand than automatic truncation).
In general, systems enforce one of two types of password rules:
- Complexity requirements ensure that users do not select
easily-guessed passwords. Example rules are: disallowing
any permutation of the user's login ID, password history,
requiring mixed letters and digits, forbidding dictionary
words, etc.
- Representational constraints limit what can be physically stored in a password field on a given system. Usually there are just two such rules: maximum length and allowable character set.
A global password policy is normally created by combining and strengthening the best-of-breed complexity requirements from each system affected by the policy. P-Synch then combines these with the most restrictive representational constraints. This forces users to select strong, secure passwords on every system.
The alternative, of defining different password policies for every target system or for groups of target systems, is considered to be user-unfriendly. To update their passwords, users must select a system, choose a password, wait for the password update to complete, possibly re-authenticate, choose another system, choose a different password, etc. Users must then remember multiple passwords and will continue to experience many password problems. It has been shown that users with many passwords have a strong tendency to write down their passwords.
Support for Incompatible Policies
Normally, it is desirable to have a single, global password policy. This makes the user experience much simpler and encourages high user adoption.
In some cases, it is impossible to formulate a single, consistent password policy that works across two different systems. Typically this happens when one system requires strong security and complex passwords, while another system simply cannot support complex passwords.
Examples of weak systems include legacy applications that use very short passwords or numeric PINs, voice mail passwords, etc.
Systems with a moderate password complexity capability typically include mainframes and database servers.
Systems with a strong password complexity capability typically include Novell NetWare, Windows Active Directory, LDAP directories and modern implementations of Unix.
If some systems have mutually exclusive password complexity capabilities, they can be grouped into mutually-compatible sets, and each set of systems is configured in its own P-Synch target group. Note that multiple P-Synch target groups can co-exist on a single P-Synch instance and do not require separate maintenance. Initial setup is just a few minutes.
Each P-Synch target group can support its own set of password policies, as well as policies regarding transparent password synchronization.
When users choose to change their passwords, they must first select a target group in the P-Synch user interface. Subsequently, appropriate policy information is displayed and enforced.
Clearly, it is preferable to formulate a single password policy for all systems whenever possible, to eliminate the password complexity which P-Synch is designed to address in the first place.