Password Settings

Password settings are stored in the backend.properties file. Some of the settings are available for editing through the interface of the "System parameters" section in the Password storage settings section.

Clearing Unused Passwords

The task of clearing unused passwords deletes all inactive passwords from the database, which are older than the lifetime at the moment of clearing. If the lifetime is equal to or less than zero, the passwords are not deleted.

The task is started by a Cron-expression, which can only be edited through backend.properties, after which the system must be restarted.

The parameter that defines the lifetime of inactive passwords can be edited through the system's interface - the "Inactive password record TTL" parameter.

Notes:

  • Because of the relatively frequent authentication events, you should not run the purge very often to avoid locking in the database and waiting for authentication for a long time. Depends on the locking settings during DELETE in the database.

  • It is recommended to launch it after business hours (if possible) or during the least busy hours.

  • The lifetime of the old password is determined by days, that is why it is not recommended to start the operation more than once a day.

Authentication Checks by Username and IP Address

In the current implementation, username validation does not capture authentication attempts by empty username (empty string, null, spaces, tabs, etc.).

The authentication attempt takes the AuthenticationRequestContext, which contains the username, client IP address, request receiving time, language and other parameters.

Before verifying the entered data, it checks whether authentication under the entered login or IP address is possible:

  • If authentication is not possible, the failed attempts counter is incremented, an error about exceeding the limit is returned, and the timeout timer is restarted.

  • If authentication is possible, the usual check for correctness of entered data goes on.

  • If data is correct, then authentication is successful and the failed counters are reset.

  • If data is incorrect, the counter is incremented, and if the limit of incorrect attempts is reached or exceeded, an error about exceeding the limit is returned.

"The limit of failed authentication attempts has been exceeded {limit}. {timeout} seconds until the next attempt" error message appears on UI when authentication error limit is exceeded.

  • limit and timeout configures in system parameters.

  • limit - Limit of failed authentication attempts for username or Limit of failed authentication attempts for client IP.

  • timeout - Authentication attempt timeout for username or Authentication attempt timeout for client IP.

Example:

Each repeated failed authentication extends the lifetime of the record.

Defined parameters: Limit - 3 attempts; Timeout - 30 seconds; Record lifetime - 30 minutes.

  1. At the first unsuccessful attempt at 15:00:00, entered data are checked, a record is created in the counter.

    • Unsuccessful attempts - 1, time of the last unsuccessful attempt - 15:00:00, record lifetime - 30 minutes.

  2. Second unsuccessful attempt at 15:01:00, entered data are checked, the record is updated in the counter.

    • Unsuccessful attempts - 2, time of last unsuccessful attempt - 15:01:00, record lifetime - 30 minutes (lifetime updated).

  3. The third failed attempt at 15:02:00, entered data are checked, the record is updated in the counter.

    • Unsuccessful attempts - 3, time of last unsuccessful attempt - 15:02:00, record lifetime - 30 minutes (lifetime updated), timeout - 30 seconds, limit reached, next attempts will be blocked until timeout expires.

  4. Fourth unsuccessful attempt at 15:02:15 - timeout has not expired, default attempt is unsuccessful, entered data are not checked, the record is updated in the counter.

    • Unsuccessful attempts - 4, time of last unsuccessful attempt - 15:02:15, record lifetime - 30 minutes (lifetime updated), timeout - 30 seconds (timeout updated), limit exceeded, next attempts will be blocked until timeout expires.

  5. Fifth unsuccessful at 15:15:00 - timeout expired, but the record lifetime has not yet expired, the record is updated in the counter.

    • Unsuccessful attempts - 5, time of last unsuccessful attempt - 15:15:00, record lifetime - 30 minutes (timeout updated), timeout - 30 seconds (timeout updated), limit exceeded, next attempts will be blocked until timeout expires.

Wrong input can be performed 3 times without timeout, after that (until the record lifetime expires) timeout will be displayed after each wrong input.

Successful authentication deletes the record, after which all 3 attempts without timeout will be available.

Known Problems

  1. If you exceed the limit on both authentications - the error will come only from one, it is not known in advance which one.

    • Possible solution: enable counters via "System Parameters" in several steps. First (with all the checks turned off) enable checking by username and save the changes. Next, enable checking by IP address and save the changes.

  2. Incorrect functioning when using a common proxy to access the system. All users will have the same IP address, therefore the counter will be incremented by different people and all users at this IP address will be blocked.

    • Possible solution: Disable the IP checking.