Open topic with navigation

Configure IDOL > Security > User Security > User Passwords

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

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

© 2016 Hewlett Packard Enterprise Development LP | Send documentation feedback to HPE Close We welcome your comments! To open the configured email client on this computer, open an email window. Otherwise, copy the information below to a web mail client, and send this email to AutonomyTPFeedback@hpe.com. Product: Topic Title: Help Topic: Feedback:

_HP_HTML5_bannerTitle.htm