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:

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

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:

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.


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.


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