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