Password policies

Password validation and generation depends entirely on the CzechIdM system. In the CzechIdM system, two kinds of policy may exist:

1. for password validation, 2. and for password generation.

Note that the password policies with the type GENERATE are used only for generating password! For maximum/minimum password age please use password policy for validation.

Every system may have two policies - one for generation, and one for validation. If any of the two policies is missing, it is replaced by the standard policy of the CzechIdM system.

When creating a new account in the system, a new password is generated using the generation policy. After the account is successfully created, the password is sent in a notification to the user (by SMS, e-mail, …). Sending of this notification can be disabled by disabling the appropriate processor, i.e. setting the application property idm.sec.acc.processor.provisioning-send-notification-processor.enabled=false.

When changing the password for the systems, including the CzechIdM system, their validation policies are used, in case of absence of the validation policy for a system, the standard validation policy is used (if there is no standard validation policy, the password is always valid - see above).

Each has its own specifications. In the whole CzechIdM, only one standard (default) policy of each kind may exist (generation/validation). When marking another policy as standard, the standard status of the previous standard policy will be canceled.

Policies may be set separately for every system.

If there is a standard validation policy in the CzechIdM system, it is used for password validation against the CzechIdM system and for all the other systems with no determined policy.

If a standard validation policy does not exist, validation of new passwords is *turned off* and passwords are always valid. Also, the "valid till" attribute is not filled.

Standard validation policy lets you validate your new password against “x” previous passwords, meaning the new one shouldn’t resemble these. Users with APP_ADMIN permission can skip this check.

The standard policy for password generation is primarily intended only for the generation of passwords used when setting up new identities in the CzechIdM system through the form. If no generation policy exists, a random password of 8 characters is generated.

The CzechIdM system offers two possibilities of password generation: random and passphrase. Password generation takes places when creating a new user on the CzechIdg system. The password can be generated again using checkbox.

When changing the password for one or more systems, the password is validated for all the found policies. If only one policy for more systems is used, only one validation takes place. When complying with all the validation rules, the password is changed on all the marked systems. In case of non-compliance, validation message will be displayed - see further below.

The password is validated through policies and it always needs to comply with the highest (maximum) requirements, i. e. minimum number of characters, maximum number of characters, minimum number of numbers, minimum number of upper-case characters, minimum number of special characters. In case the requirements of two policies turn out to be contradictory (e.g. the minimum number of characters of one policy is lower than the maximum number of characters of another policy), and so the password WILL NEVER BE marked as valid, then it is the task of the CzechIdM system administrator to remedy the situation.

The change of password can also be impossible due to minimum validity of the password - this piece of information is verified when validating the password.

As for password generation every policy enables to set up character bases from which the password will be generated. For both types of password policies (generation/validation), it is also possible to define forbidden characters for the whole password and sets of characters, which password must not start or end with. When being validated/generated, the password is tested for presence of these forbidden characters. In case of password validation the user is informed about using such characters in the password. When a password is generated, forbidden characters are omitted during the process of generation.

The standard values of the character sets are not saved to the policies but they are gathered from the class PasswordGenerator (static variables).

If enhanced control of the validation password policy is enabled (see picture below), user can specify User attributes not allowed in password to which password must not resemble. Otherwise the password is not possible to be used. Motivation for this feature is to be able to set more strict rules for password policy, which are sometimes enforced by target systems (e.g. MS Active Directory). The manner of the similarity assessment is inspired by password complexity requirements by Microsoft MS password requirements. It suggests to split attributes into individual substrings by delimiters, if present, and then check the password for substring presence. As delimiters are considered following characters inside quotation marks ", . - — _ £" and white space characters such as spaces, tabulators etc. If some substrings are shorter then 3 characters, they are omitted from validation. Validation is case insensitive and also insensitive to accents/diacritic.

IdM supports check of following attributes:

* Email * Username * First name * Last name * Personal number * Titles before name * Titles after name

Not all attributes are treated the same way. They can be divided into 3 groups. according to the approach to the assessment of similarity.

1) Email is tested whether it is contained in the password as a whole. Example: for email: j.doe@provider.com passphrases: XYZj.doe@provider.com, j.doe@provider.comXXX etc. are assessed as invalid. On the other hand passwords: jdoe, doe@provider etc. are valid.

2) Titles after/before name have, beside some exceptions, similar form containing several characters ended by period sign (e.g. Prof. MUDr.). When titles are processed, period sign is removed and created string is split by delimiters. This approach prevents from falling apart of titles containing delimiter somewhere in the middle (e.g. Ph.D.).

3) User name, First/Last name and Personal number are treated according to the above mentioned general procedure. E.g. person with name "Erin M. Hagens" is first split into "Erin" "M" "Hagens" substrings. Then "Erin", "Hagens" are checked for presence in the password. "M" is not considered because it is shorter than 3 characters. Passwords such as Hagens1234, ErinIsGreat etc. are invalid.

The main part of the advanced check of the password is the option to set up which of the rules are mandatory, and which are not. The control mechanism is as follows:

To each of the rules (see the rules list below), you may assign the feature saying whether the rule is mandatory or not. If the rule is marked as mandatory, it must be always satisfied. In case the rule is not mandatory, the number of satisfied optional rules must be higher or equal to the minimum feature of the rules to comply with the policy. For a better understanding, you can read the description of the following UseCase, including the settings.

The administrator of the CzechIdM system has set up that the passwords must always include at least one number, the number of password characters amounting exactly to 8 characters. Then it must contain one special character, or two upper-case characters - it doesn´t matter which one of the two rules will be met.

Basic policy settings:

To satisfy the requirement of the password having at least one special character, OR two upper-case characters, an advanced check with the following settings will be used:

The validation messages with an unmet advanced check of the password looks as follows:

When users want to change their password in IdM, they are required to fill their old password (unless the configuration attribute requireOldPassword is set differently, see below). It's possible that their local password in CzechIdM is distinct from their password in end systems. In that case, users must use the password which satisfies the authentication chain (the same authentication chain that is used during authentication - same rules, same order of processing). If the (old) password is validated successfully, users can change their password.

The configuration attribute idm.pub.core.identity.passwordChange.requireOldPassword= determines whether the users are required to fill in the old password when changing their password. The possible values are:

• true - the old password is required,
• false - the old password is not required.