User Passwords

The Community component can authenticate users in a number of different ways, either by using a local password, or by communicating with external servers such as LDAP or NT Domain. This section looks at local password use, and describes the various parameters available to control password security and settings. It also describes how passwords are stored in IDOL Server.

To use local authentication, the autnsecurity library must be configured in the configuration file. This library is the default authentication mechanism for Community. If you want to use another authentication mechanism, you must explicitly state it in the appropriate ACI actions (Security and UserRead). You can change the default authentication mechanism by using the DefaultSecurityType configuration parameter.

The following sections describe the configuration parameters that you can use to control passwords and authentication. For more details about these parameters, refer to the IDOL Server Reference.

Password Storage

Community does not store user passwords in plain text. It uses the Blowfish hashing algorithm to generate a hashed string. It then encodes this hash in base64, along with a few other pieces of information such as the salt and salt length. This generated string is stored in the Community component database.

When a user attempts to authenticate their password using Community, the same procedure is applied to the input password, and the resulting string is compared with the stored one. If they are identical, the user is successfully authenticated. The Blowfish algorithm is a one-way process, so it is impossible to deduce the password from the generated string.

The PasswordHashMaxIterations and PasswordHashSaltLength configuration parameters both affect salt generation. The salt is a small amount of random data added to the hashing process, designed to defend against dictionary attacks and other hack attempts. The PasswordHashMaxIterations parameter directly alters several characters in the generated salt, while the PasswordHashSaltLength parameter affects the length of the salt. In most cases, the default values for these parameters are appropriate. Do not change the values of these parameters after users have started storing passwords.

Password Constraints

You can define constraints for the passwords that users can set, using the following configuration parameters:

  • MaxNumPasswordPerUser relates to the password history feature. Community stores the previous N passwords for each user, and prevents a user from reusing any of these passwords when they change it. This parameter provides the value for N. If you do not want to store the password history, set the parameter value to 0.

  • MinPasswordLength enforces the minimum length allowed for passwords. Micro Focus recommends that if you use this feature, you set a value of at least eight.

  • PasswordStrength implicitly defines the minimum set of characters passwords can be drawn from; for example, lowercase and uppercase letters, numbers, punctuation, and so on. If the value is N, it means that if an attacker program tries all combinations of characters and can examine 1 million strings per second, it would take at least eN days to finish in the worst case. In general, a value of 1-2 means weak, 3-5 means acceptable, and 5-10 means strong. Micro Focus recommends that you set a minimum value of 3. A higher value means that users must use more sets of characters in their passwords.

You can also control how long a user can use their current password before they must change it:

  • PasswordChangeDuration specifies the maximum length of time for which a user can keep a password.

  • KeepPasswordDuration specifies the minimum length of time allowed after a password change before the user can change the password again.

Micro Focus recommends that you do not set PasswordChangeDuration to be too high, and do not set KeepPasswordDuration to be too low. Sensible values for these parameters are three months and one month, respectively. To avoid using this feature, set these parameters to -1.

User Locks

User locking prevents access to a user account. In IDOL Server, a user lock can be triggered in one of the following ways:

  • A user attempts to authenticate with incorrect credentials more than the number of times specified by the LoginMaxAttempts configuration parameter, within the amount of time specified by the LoginExpiryTime configuration parameter.

  • An administrator explicitly locks a user account by using the UserLock action.

  • A user account is inactive for the configured InactiveUserLockCycleDuration.

The value to use for the LoginMaxAttempts parameter depends on your application, because the seriousness of failed authentication varies for different applications. However, Micro Focus recommends that if you use this configuration, you do not set the value too high or too low. For most applications, a value of 3 is sufficient. You can set LoginMaxAttempts to -1 to turn off this method of automatic user locking.

You can use the LoginExpiryTime parameter in conjunction with LoginMaxAttempts to specify the period of time before the number of unsuccessful authentication attempts is reset. If a user makes LoginMaxAttempts unsuccessful attempts with the specified LoginExpiryTime, the account is locked. The count of unsuccessful attempts resets after the expiry time, or whenever the user makes a successful authentication attempt.

LoginMaxAttempts=3
LoginExpiryTime=3600

In this example, if a user makes two failed authentication attempts in an hour, and than another an hour later, IDOL does not lock the account, because the expiry time has reset.

The correct value to use for LoginExpiryTime depends on your application. Any value more than a few seconds slows down a potential attacker, but a higher value might be better. You can set LoginExpiryTime to -1 if you do not want to periodically reset the count.

By default, only an administrator can unlock a user account, by using the UserLock action. You can configure IDOL Server to automatically unlock a user after a specified amount of time, by setting the LockRemovalDuration parameter. You can also set this parameter to -1, in which case an administrator must manually unlock the user account.

Inactive Users

IDOL Server can automatically lock or delete users who have not authenticated recently. The InactiveUserLockCycleDuration and InactiveUserDeleteCycleDuration parameters determine how frequently IDOL checks for inactive users. The InactiveUserLockDuration and InactiveUserDeleteDuration parameters control how long a user must be inactive for before IDOL takes action to lock or delete the user account. The correct value to set for these parameters depends on your application, but higher values are more sensible than lower ones for all these parameters. You can set each parameter to -1 to turn off inactive user locking and deletion.

NOTE: If you have set the LockRemovalDuration parameter, IDOL automatically unlocks users that have been locked by any method, including inactive users.