/
Password policy

Password policy

Owned by Nick Jensen
Last updated: Feb 11, 2015 by Troels Nielsen
Article excerpt

Description of the various dialogportal™ REST API password restrictions and security settings 

Request a change of password policy

If you would like to update your password policy, please contact your Fluid liaison

Table of Contents

Password policy and management

Password hashing

When password hashing is enabled, passwords are no longer stored directly in the database, but rather an alphanumeric "hash" is saved. When a user subsequently attempts to log into the system, the login password is hashed in the same way as the stored password hash, and if the resulting login hash matches the stored hash, then the login succeeds. The user password is not stored anywhere in plain text, and cannot be retrieved - the only option when the user has forgotten their password is to reset it.

Password restrictions

There are various options for restricting valid passwords, only the first is a fixed restriction, applicable to all customers and accounts:

  1. The password may not be the same as, or contain the user ID (variously referred to as the entityID, SubjectRelationID or SRID) (always applies)

  2. Minimum length (optional)
  3. Minimum number of numeric digits (optional)
  4. Minimum number of letters (actually defined as anything not a numeric digit, so includes symbols etc.) (optional)

Password expiry

A password lifetime (in days) may be specified, in which case authentication will fail after the password has expired. Changing or resetting the password before it expires resets the password lifetime. After a password has expired it is no longer possible to change the password through the REST API - the password must be reset, by making a forgotten password request.

When requests are made to endpoint 2001: Authenticate and a password lifetime is defined, the password expiry date is returned as response header PasswordExpires.

Password history

When password history is enabled, a history size (number of previous passwords) is specified, and users are prevented from changing their password to anything that has previously been used within this history size. When password hashing is enabled, this password history contains the hashes of previous passwords.

Additionally, a cooldown period may be defined, where the password may not be changed more than once within the time period.

System lockout

A maximum number of login attempts may be specified. After the maximum number of incorrect login attempts is made, the account is locked for given a lockdown period. During this time, no login will succeed, whether or not the password is correct.

A password reset, triggered by a forgotten password request, will reset the lockout and allow the user to log in with their new password.

Forgotten password

Password reset

When a user forgets their password and requests a password reset, an email is sent to them containing a link to a reset page. Here the user enters their desired new password twice, and if it meets the validation criteria (described above) then the new password is saved. The reset link is only valid for a limited period of time, and can only be used once. If the limit expires, then a new password reset request must be made.

Password reminder

Alternatively, when password hashing is not used, the "forgotten password" email may be configured to contain the user password. In this case a reset is not required, the user can simply log in as usual with their usual password. This option is inherently less secure than using hashed passwords and the password reset system, but may be an option in specific scenarios.

Related content