libre.sh/keycloak-scim
4
0
Fork 0
Code Issues 15 Pull requests Releases 1 Activity Actions

Improve brute force documentation around how the effective wait time is calculated

Browse source 
Closes #25915

Signed-off-by: Pedro Igor <pigor.craveiro@gmail.com>
Co-authored-by: Alexander Schwartz <alexander.schwartz@gmx.net>
Co-authored-by: andymunro <48995441+andymunro@users.noreply.github.com>
This commit is contained in:
Pedro Igor 2024-01-09 04:50:17 -03:00 committed by GitHub
parent 5e0e7254a0
commit 7fad0e805e
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 25 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

27
docs/documentation/server_admin/topics/threat/brute-force.adoc
View file

@ -20,7 +20,8 @@ To enable this protection:
.Brute force detection
image:images/brute-force.png[]
{project_name} can deploy permanent lockout and temporary lockout actions when it detects an attack. Permanent lockout disables a user account until an administrator re-enables it. Temporary lockout disables a user account for a specific period of time. The time period that the account is disabled increases as the attack continues.
{project_name} can deploy permanent lockout and temporary lockout actions when it detects an attack. Permanent lockout disables a user account until an administrator re-enables it. Temporary lockout disables a user account for a specific period of time.
The time period that the account is disabled increases as the attack continues and subsequent failures reach multiples of `Max Login Failures`.
[NOTE]
====
@ -74,7 +75,8 @@ When {project_name} disables a user, the user cannot log in until an administrat
|15 minutes.
|Failure Reset Time
|The time when the failure count resets. The timer runs from the last failed login.
|The time when the failure count resets. The timer runs from the last failed login. Make sure this number is always greater than `Max wait`; otherwise the effective
wait time will never reach the value you have set to `Max wait`.
|12 hours.
|===
@ -94,6 +96,27 @@ When {project_name} disables a user, the user cannot log in until an administrat
`count` does not increment when a temporarily disabled account commits a login failure.
====
For instance, if you have set `Max Login Failures` to `5` and a `Wait Increment` of `30` seconds, the effective time an account will be disabled after several failed authentication attempts will be:
[cols="1,1,1,1"]
|===
|`Number of Failures` | `Wait Increment` | `Max Login Failures` | `Effective Wait Time`
|1 |30 | 5 | 0
|2 |30 | 5 | 0
|3 |30 | 5 | 0
|4 |30 | 5 | 0
|**5** |**30** | 5 | **30**
|6 |30 | 5 | 30
|7 |30 | 5 | 30
|8 |30 | 5 | 30
|9 |30 | 5 | 30
|**10** |**30** | 5 | **60**
|===
Note that the `Effective Wait Time` at the 5th failed attempt will disable the account for `30` seconds. Only after reaching
the next multiple of `Max Login Failures`, in this case `10`, will the time increase from `30` to `60`. The time the account will be disabled
is only increased when reaching multiples of `Max Login Failures`.
The downside of {project_name} brute force detection is that the server becomes vulnerable to denial of service attacks. When implementing a denial of service attack, an attacker can attempt to log in by guessing passwords for any accounts it knows and eventually causing {project_name} to disable the accounts.
Consider using intrusion prevention software (IPS). {project_name} logs every login failure and client IP address failure. You can point the IPS to the {project_name} server's log file, and the IPS can modify firewalls to block connections from these IP addresses.