LOCKOUTTHRESHOLD - Detailed description

Overview

Parameters:LOCKOUTTHRESHOLD
Category: Login
Default value: 0
Product: eTASK.Login

What does this parameter do?

Sets the number of consecutive failed login attempts within the time specified in FAILEDLOGINCOUNTERWITHINMINUTES before the account is locked. The default value is 0. If set to 0, the check is not performed and accounts are never automatically locked, regardless of the number of failed attempts.

What is this parameter used for?

• Protection against brute-force attacks by locking accounts

• Defining the tolerance threshold for failed login attempts

• Automatic activation of security mechanisms in case of suspicious activity

• Balancing user-friendliness and security

• Adherence to security policies and compliance requirements

• Defense against automated password brute-force attempts

• Reducing the risk of successful account compromise

Technical Details (for Administrators)

Format: Integer
Default value: 0

Valid values:

• 0 = No automatic lockout - no check is performed

• 1 to 999999 = Number of allowed failed attempts before account lockout

Important notes:

• If the value is 0, there is NO automatic account lockout, regardless of failed attempts

• The counter only counts failed login attempts within the time window defined in FAILEDLOGINCOUNTERWITHINMINUTES

• After a successful login, the failed login counter is reset to 0

• The account is automatically locked when the threshold is reached or exceeded

• The threshold does not apply in the case of manual lockout by administrators

• The lockout duration is determined by LOCKOUTDURATIONMINUTES

• Only consecutive failed login attempts within the time window are counted

Interaction with other parameters:

• LOCKOUTDURATIONMINUTES: Defines the duration of the lockout in minutes after the threshold is reached

• FAILEDLOGINCOUNTERWITHINMINUTES: Defines the time window during which failed login attempts are counted

When should you change this value?

Leave the value at 0 (default - no lockout) if:

• You do not want automatic account lockout

• Other security mechanisms are in place

• The system is purely internal with no external threats

• User-friendliness is the top priority

• Manual account locking by administrators is preferred

Set the value to 3–5 (Strict Security) if:

• High security requirements exist

• Sensitive data must be protected

• The system is accessible from outside

• Brute-force attacks pose a realistic threat

• Compliance requirements mandate strict security

• Quick protection against attacks is important

Set the value to 5–10 (Moderate Security) if:

• A balance between security and user-friendliness is desired

• There is a moderate security threat

• Accidental input errors should be tolerated

• A standard corporate environment is in place

• Users occasionally forget passwords

Set the value to 10+ (user-friendly) if:

• Very high user-friendliness is a priority

• There is a low security threat

• Many accidental input errors are expected

• Internal systems with no external exposure are present

• Minimal security requirements exist

Important notes

1. A value of 0 completely disables automatic
   locking With a default value of 0, there is NO automatic account locking, regardless of how many failed attempts occur. This poses a significant security risk for externally accessible systems.

2. Coordination with FAILEDLOGINCOUNTERWITHINMINUTES
   The threshold only applies to failed login attempts within the defined time window. Failed attempts outside this time window reset the counter.

3. Manual vs. automatic lockout
   Administrators can manually lock accounts at any time, regardless of the threshold. This parameter applies only to automatic lockout.

4. Failed attempt counter is reset upon success
   A successful login resets the counter to 0. Subsequent failed attempts then start again at 1.

5. Too low a value can lock out
   legitimate users A threshold of 1–2 is very strict and can lock out users who make a typo on their first attempt.

6. Too high a value weakens security
   Values above 10 give attackers many attempts and significantly weaken brute-force protection.

Security

Does changing this parameter affect security?

Yes, changing this parameter has a significant impact on security.

Positive aspects:

• Enabling this feature (value > 0) effectively protects against brute-force attacks

• Significantly limits the number of password attempt attempts

• Automatic response to suspicious login activity

• Reduces the risk of successful account compromise

• Complies with common security best practices

Note:

• A value of 0 (default) offers NO protection against brute-force attacks

• Values that are too high (>10) significantly weaken protection

• Values that are too low (1–2) can lead to frequent lockouts of legitimate users

• Without LOCKOUTDURATIONMINUTES configuration, the lockout is ineffective

• Attackers can deliberately lock out many accounts (denial-of-service)

• When lockout is enabled, users must be informed of the policy

Data protection assessment:

• Account lockout is a legitimate security interest

• Failed login attempts should be logged

• Users should be informed about the lockout mechanism

• Automatic unlocking (via LOCKOUTDURATIONMINUTES) minimizes intervention

notedc0e9de9-1887-464b-a958-75036bda4bad

Recommendation: Enable LOCKOUTTHRESHOLD with a value between 3 and 5 for production environments with external accessibility. Never use the default value of 0 on publicly accessible systems. Coordinate the value with LOCKOUTDURATIONMINUTES and FAILEDLOGINCOUNTERWITHINMINUTES for a balanced security strategy. Document the configuration for compliance audits.

Recommendation: Enable LOCKOUTTHRESHOLD with a value between 3 and 5 for production environments accessible from the outside. Never use the default value of 0 on publicly accessible systems. Coordinate this value with LOCKOUTDURATIONMINUTES and FAILEDLOGINCOUNTERWITHINMINUTES to ensure a balanced security strategy. Document the configuration for compliance audits.

Practical Example

Initial situation: A company operates an externally accessible portal with LOCKOUTTHRESHOLD=0 (default value). The security team notices that failed login attempts are occurring on various user accounts. Automated bots may be systematically attempting to guess passwords. Since no automatic lockout is active, potential attackers can make an unlimited number of attempts.

Configuration: The administrator sets LOCKOUTTHRESHOLD=3, LOCKOUTDURATIONMINUTES=60, and FAILEDLOGINCOUNTERWITHINMINUTES=10.

After the change:

• User accounts are automatically locked for 60 minutes after 3 failed login attempts within 10 minutes

• Brute-force attacks are blocked after a maximum of 3 attempts

• After the first 60-minute lockout, only ONE additional attempt is allowed (counter is not reset)

• Realistically, attackers can only test about 25–30 passwords per account per day

• Automated attacks become practically ineffective

• Legitimate users have 3 attempts, which is sufficient for normal typos

Result: Massively improved protection against brute-force attacks with minimal impact on legitimate users. The combination of these three parameters creates a robust security concept that effectively prevents automated attacks.

Alternative scenarios:

Scenario A - High-security environment (financial sector):

• LOCKOUTTHRESHOLD=3

• LOCKOUTDURATIONMINUTES=120

• FAILEDLOGINCOUNTERWITHINMINUTES=30

• 2-hour lockout after 3 failed attempts

• Maximum protection for sensitive financial data

Scenario B - User-friendly environment:

• LOCKOUTTHRESHOLD=5

• LOCKOUTDURATIONMINUTES=30

• FAILEDLOGINCOUNTERWITHINMINUTES=15

• Moderate security with higher fault tolerance

• Allowing 5 attempts accommodates occasional typos

• Suitable for portals with low external threat

• Balance between security and productivity

Scenario C - Legacy System Migration:

• Initial situation: LOCKOUTTHRESHOLD=0 (no lockout)

• Gradual implementation: Phase 1 with LOCKOUTTHRESHOLD=10, then reduce by 2 each month

• Final configuration: LOCKOUTTHRESHOLD=3

• Users gradually adapt to the new security policy

• Helpdesk can adapt processes and documentation

• Reduced number of support requests due to a smooth migration

Recommended setting

For standard installations:3(3 failed attempts)

Reason:

• Strict protection against brute-force attacks

• A low number of allowed attempts minimizes the attack surface

• Sufficient tolerance for legitimate users who make typos

• Complies with common security best practices

• Meets typical compliance requirements

Tip: Monitor login statistics for 2–4 weeks after activation. Pay attention to:

• Number of automatic lockouts per day

• Ratio of legitimate users to attackers

• Help desk inquiries regarding locked accounts

• Patterns in failed login attempts