Password policies password security configuration

If there is a standard validation policy (in the code we talk about default 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. In the service IdmPasswordPolicyService there are three methods of validation, all of them accepting IdmPasswordValidationDto as a parameter containing new password, the IdmPassword object, and the identity to which the password belongs to. Another parameters of the validate methods is a list or one object itself IdmPasswordPolicy. There is also a possibility of validation only with the object IdmPasswordValidationDto, standard policy will be used for its validation, if applicable.

The identity is also part of the object IdmPassword but this object does not necessarily need to exist, like e.g. synchronization with the system.

If the standard validation policy does not exist, the validation of new passwords is turned off and the password is always valid, also the attribute "valid till" will not be filled.

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.

For generation, there are methods in IdmPasswordPolicyService available, marked as generate. As a parameter, the methods accept the object IdmPasswordPolicy, this policy must be of the GENERATE type. Or, as the case may be, a method without parameters may be used. In this case, standard generation policy is used; if it doesn´t exist, a random password of 8 characters is generated.

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).

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.

A random password is generated depending on the minimum number of characters set up in the policy. Password generation takes place against characters bases which are part of every policy. Forbidden characters are removed from these bases and then a password with a minimum number of characters defined by each of the rules is generated (minimum number of numbers, minimum number of special characters, etc.). Then the password is completed by different characters up to the minimum number of characters, and finally with a random number of characters ranging between the minimum and the maximum number of characters. After being generated, the whole password is jumbled up. All this process takes place in the class PasswordGenerator. The PasswordGenerator does not accept the password policy as a parameter, but the interface PasswordGenerate.

The second option is to generate the password using passphrase. Again, the password generation is done by PasswordGenerator. For the purposes of passphrase generation, a dictionary which can be found in diceware_cs.csv is necessary.

Examples of passphrase generation containing 5 words

masitou karibska kartaga dotovany cipy
nesnadny odvijela cedicova zapolici projel
bunicito tesnenim udelaji zatahnut lenoseni
agend civilnim udrzbou kopati odvsiven

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.

In case of non-compliance with one or more policies, the validation message will be displayed, which contains the information for which policies the password turned out to be invalid and why.

The display of the validation message is ensured by the component ValidationMessage. The component displays only the validation messages related to validation processing. The detailed procedure of performance of the individual messages can be found in DefaultIdmPasswordPolicyService the validate method and the variable Map<String, Object> errors.

As for password generation, every policy enables to set up from which characters the password will be generated. For both types of password generation (generation/validation), it is also possible to define the forbidden characters. When being validated, the password is verified for these forbidden characters.

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

As a part of the password check, it is possible to turn on an advanced check. Within the advanced check, you can set which identity attributes (PasswordPolicyIdentityAttributeEnum) are verified for the similarity of passwords - e.g. when there is a correspondence between the name and the password, the password is marked as 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:

• minimum and maximum number of the password,
• minimum number of upper-case characters,
• minimum number of lower-case characters,
• minimum number of numbers,
• minimum number of special characters,

In the CzechIdM system, there are no passwords saved in plain text or a decipherable form. The object IdmPassword is assigned to the identities, the link exists from IdmPassword to IdmIdentity, but not the other way around. Not every identity necessarily needs to have a password.

The object IdmPassword has the following attributes:

• password (string) - a password in an indecipherable form saved by the BCrypt algorithm, including salt,
• identity (IdmIdentity) - the identity to which the object belongs

  • validTill (datetime) - date until which the password is valid, the date has been taken over from the policy
  • valid_from (datetime) - date from which the password is valid, at present for information only, always set according to the latest change
  • mustChange (boolean) - in case this feature has been set up, after logging in, the user is redirected to the password change Until the password is not changed, access to the CzechIdM system is not allowed.

After using Bcrypt, the question is what the maximum number of password characters is. When using passphrase, you get even more than 255 characters.

Password with 300 characters: the password creation and the log-in were successful. The generated hash always had the same number of characters, including salt; e.g. ($2a$12$ZWIqBjjZrONY2Nw5V8VyOesVw2/naVq.N0oR/CAxabozI5KONxScK), so there is no dependence on the number of characters of the password and the hash.

If user want change password by public change password (REST endpoint: /public/identities/{backendId}/password-change) is necessary know old password. In this moment is not required that identity has password in our system (identity is get by synchronization and object idm_password for this identity don't exist). After public password change is old password check by all authentication chain see AuthenticationManager and password will be changed on all system including IdM.

Public password change is also validate by password policies via PasswordPolicyService (validation by policies including default policy and system policies).

• Password history,
• dictionary of weak words,
• nice generation of random passwords,
• statistics of unsuccessful attempts to change the password.