16.7. Failed factor attempts

Counting failed attempts on authentication factors and locking user accounts based on such counters is crucial for overall account security.
The flow infrastructure counts failed attempts individually for every authentication factor, i.e. for every authentication factor, there is a separate counter.

For every verifying step, an Authentication Method ID must be configured (or is sometimes hard-coded). The Authentication Method ID determines which failed factor counter is used to count failures.
The failed factor attempts counters are independent of flow types. It is therefore possible to define individual counters for every authentication method and to use these counters in all types of flows.

The following rules apply:

Counter selection
The Authentication Method ID identifies the failure counter. Every authentication method verifying step supports the configuration of the Authentication Method ID.
Failure handling
All failed factor checks of authentication method verifying steps cause the failed factor counter for the corresponding authentication method to be increased.
Max failed attempts counter exceeded
As soon as any one of the failed attempts counters exceeds the configured limit, the user is locked.
Success handling
When a flow is finished successfully, all counters for steps that have been processed (and not skipped) during this flow will be reset to 0.
The failed factor counters for authentication methods that are skipped or not used remain unchanged.
Admin unlock
When a user is unlocked by an administrator, all failed factor attempts counters are reset to 0.
Unlock self-service
When a user successfully unlocks an account, all configured failed factor attempts counters are reset to 0.
Failed factor attempts within the unlock self-service also increase the corresponding counter.
Independent steps
Steps that don't verify authentication methods (e.g. terms of services step) don't cause counters to be increased.
Exceptions
Authentication Step Results may define that a specific result (e.g. password policy violations) should not count as a failed factor attempt.

Failed factor attempt counters are not available when using MSAD as the sole persistence layer. See 6.2.3. Microsoft Active Directory (MSAD) for Airlock IAM for resulting limitations.

Example – Failed factor attempts counters

The following example shows how user actions in an authentication flow affect the failure counters. The example flow uses a password, Airlock 2FA, and mTAN.

User Action
PASSWORD
mTAN
Airlock 2FA
The flow has not yet started, but the account already contains failure counters from the last login attempts.
2
0
0
The user provides an incorrect password.
3
0
0
The user provides the correct password.
3
0
0
The user provides an incorrect mTAN.
3
1
0
The user switches to Airlock 2FA.
3
1
0
The user provides the correct passcode.
3
1
0
The user is forced to change the password and provides an incorrect old password.
4
1
0
The user provides the correct old password, but the new password does not match the policy requirements.
4
1
0
The user provides the correct old password and the new password matches all requirements.
4
1
0
The flow completes successfully. All failure counters of successfully used factors are reset.
The user is logged in.
0
1
0

Configuration of failed factor attempt counters

The identifiers used as failed login counters can be configured on steps involving an authentication factor in the property Authentication Method ID. In some steps, the ID is hard-coded and cannot be changed.

Distinct authentication method identifiers may be chosen, if multiple instances of the same step type are used to check different credentials (e.g., two password step instances check two different passwords).

Example: multiple password credentials

A system tracks two passwords per user. Password 1 is used in flow A, password 2 in flow B. The two steps should have distinct Authentication Method IDs, e.g. PASSWORD1 and PASSWORD2. If only one identifier (e.g. PASSWORD) is used to track failed factor attempts, this may allow brute force attacks if one of the passwords is already known.

If attackers know the user's Password 1, they get an unlimited number of attempts on Password 2, as the PASSWORD counter can repeatedly be reset to 0 by performing a successful login on flow A. To prevent such attacks, use two different counters by setting different Authentication Method IDs e.g. PASSWORD1 and PASSWORD2.

Unlock User Step (Public Self-Service)

It is possible to configure public self-service flows that unlock a user account.

  • Such a flow typically uses the following sequence of steps:
  • 1.
    User Identification Step (Public Self-Service)
  • 2.
    E-Mail Identity Verification Step or some other identity verification step.
  • 3.
    Airlock 2FA Public Self-Service Approval Step or another step that uses an authentication factor to approve the account unlock.
  • 4.
    Unlock User Step (Public Self Service) to reset the failure counter of a particular Authentication Method ID (typically for the password).

In the above example, the Unlock User Step (Public Self Service) is secured by verifying a communication channel (e-mail, mTAN) with the user and then using a 2nd authentication factor to confirm the user identity.

Further information and links