Skip to main content

Authentication protection

The authentication protection feature protects the ConSol CM system against brute force attacks as dictionary attacks, credential stuffing and password spraying. All failed login attempts are logged in the database and users are automatically blocked after a configurable number of failed attempts.

The authentication protection covers database and LDAP authentication for all authentication endpoints:

  • User authentication in the Web Client and Web Admin Suite
  • Contact authentication in CM/Track using the REST API
  • Authentication of webhooks

All failed login attempts are logged in the database and the account is blocked after a defined number of failed attempts for a certain time period. A notification email is sent to the administrator and to the affected user.

info

Not all failed login attempts are due to brute-force attacks. A failed attempt is also logged if the affected account is deactivated or configured incorrectly. The reason of the failed attempt is shown in the Last authentication attempts tab. Therefore, you can also use this feature to get further information why an attempt fails. If the login fails due to problems with the LDAP server (authentication methods LDAP and DATABASE,LDAP only), the account is not blocked.

Accounts can be unblocked either automatically after a defined time period or manually, either in the Web Admin Suite or using an unblock link.

By default, the authentication protection is enabled for all endpoints and default settings are used for the number of failed attempts and the time period, see Fine-tuning authentication protection.

Available information​

The Authentication protection page consists of three tabs.

Blocked accounts​

This tab shows the accounts which are currently blocked. The following information is available:

  • Name: The name of the user whose account is blocked.
  • Email: The email of the user whose account is blocked.
  • Type of entity: The type of account. This can be:
    • User: User managed on the Users page, relevant for access to the Web Client and Web Admin Suite.
    • Contact: CM/Track user managed in the Web Client, relevant for access to CM/Track and the REST API.
    • Endpoint: Webhook with secret token as a security method, see Webhooks.
  • Failed attempts: The number of failed attempts.
  • Blocking date: The date and time when the account was blocked.

You can unblock accounts on this page.

Last authentication attempts​

This tab shows the 100 last authentication attempts. The following information is available:

  • Name: The name of the user whose account is blocked.
  • Email: The email of the user whose account is blocked.
  • Type of entity:
    • User: User managed on the Users page, relevant for access to the Web Client and Web Admin Suite.
    • Contact: CM/Track user managed in the Web Client, relevant for access to CM/Track and the REST API.
    • Endpoint: Webhook with secret token as a security method, see Webhooks.
  • Reason for attempt failure: The reason why the authentication attempt failed. This can be:
    • Blocked: Attempt to log in to a blocked account.
    • Inactive: The user or contact is deactivated, or the customer group of the contact is deactivated.
    • LDAP error: Failed attempt to use LDAP authentication, e.g. due to the LDAP server being down.
    • No portal profile: The contact does not have a portal user profile assigned.
    • Unknown name: Attempt to log in to a non-existing account.
    • Wrong password: Attempt to log in to an existing account with a wrong password / secret.
  • Date: The date and time of the failed attempt.

History of blocked accounts​

This tab shows the accounts which were blocked in the past 100 days and are now unblocked. The following information is available:

  • Name: The name of the user whose account was blocked.
  • Email: The email of the user whose account was blocked.
  • Type of entity: The type of account. This can be:
    • User: User managed on the Users page, relevant for access to the Web Client and Web Admin Suite.
    • Contact: CM/Track user managed in the Web Client, relevant for access to CM/Track and the REST API.
    • Endpoint: Webhook with secret token as a security method, see Webhooks.
  • Blocking date: The date and time when the account was blocked.
  • Unblocking date: The date and time when the account was unblocked.
  • Unblock type: The method of unblocking the account. This can be:
    • Administrator: The account was unblocked manually by an administrator.
    • Block period elapsed: The account was unblocked automatically after the defined time period.
    • Unblock code: The account was unblocked manually by a user or administrator using the unblock link.

Basic tasks​

Unblocking an account​

There are three ways of unblocking an account:

  • The account is unblocked automatically after the defined time period elapsed.
  • The account is unblocked by an administrator in the Web Admin Suite. This is done in the Blocked accounts tab by clicking the Unblock icon of the respective row. You can also select several accounts to unblock them at once.
  • The account is unblocked by the affected user by clicking an unblock link in the notification email. In the Web Client, this opens a page which indicates if the account was unblocked successfully, so the user can log in again. In CM/Track, the user must click the Unblock my account button on the page to be able to log in again. In case of a webhook, the administrator receives the email with the unblock link.
URLs

The unblock links sent by email only work if the system properties url.track and url.webclient from the module cmas-core-server are set correctly.

Advanced tasks​

Fine-tuning authentication protection​

You can fine-tune the authentication protection feature using system properties from the module cmas-core-security.

  • Enable the authentication protection: You can enable (true) and disable (false) the authentication protection by setting the desired value in the property for the respective endpoint:

    • Users: brute.force.engineer.blocking.active
    • Contacts / REST users: brute.force.unit.blocking.active
    • Webhooks: brute.force.endpoint.blocking.active

    By default, the feature is enabled for all endpoints.

  • Determine when an account is blocked: You can configure how many failed attempts are needed to block an account in the system property brute.force.attempts.to.block. The period for counting the failed attempts is defined in brute.force.period.between.attempts.to.block.

    By default, an account is blocked after 7 failed attempts within 1 minute.

  • Configure automatic unblocking: You can enable (true) or disable (false) the mechanism to automatically unblock an account in brute.force.auto.unblock.active. The time period after which an account is unblocked is defined in brute.force.auto.unblock.period.

    By default, automatic unblocking is enabled and accounts are unblocked after 30 minutes.

  • Configure notifications: You can decide whether blocked users and contacts should receive an email with a link to unblock their accounts in brute.force.mail.notification.active. If this property is set to true, the users and contacts can unblock their accounts by clicking the link. The links expire after the time configured in brute.force.unblock.code.expiration.period. The administrator also receives emails with information about the blocked accounts and the unblock links. In addition, the administrator receives an alert if the number of failed attempts exceeds the value set in brute.force.admin.auth.failures.notify.amount in the time period configured in brute.force.admin.auth.failures.notify.period.

    By default, no emails are sent. If notifications are enabled, the unblock links expire after 24 hours, and the administrator is notified if more than 100 failed attempts occur within 60 minutes.