Open topic with navigation
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 (
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.
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.
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.
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
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
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
A user account is inactive for the configured
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
-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
-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.
IDOL Server can automatically lock or delete users who have not authenticated recently. The
InactiveUserDeleteCycleDuration parameters determine how frequently IDOL checks for inactive users. The
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.