6:58 p.m.
I put this in the PR and corresponding JIRAs, but a user had this
problem in 3.2 (not 3.4, I fixed it)
1) User has 3 failed attempts, account locks, Temporary Disable appears
2) User tries again before wait period is up...Wait increment
increases wait time
3) User tries again before wait period, wait increment is increased
again as Keycloak logged a failure for this
4) User is locked out forever unless admin helps to unlock.
So, I changed the behavior so that a failure isn't logged if a user
attempts a login to an account that is temporarily blocked. I believe
the failure count is only reset on a successful login.
IMO, the algorithm shoudl be:
1) After N failed attempts lock user for WAIT TIMEOUT
2) Do not increment failure count if login is attempted on locked account
3) After N failed attempts after unlock, lock user again for WAIT TIMEOUT * 2
4) After unlock and another N failed attempts, locak user again for
WAIT TIMEOUT * 3.
5) A successful login resets failure count.
On Tue, Feb 6, 2018 at 1:13 AM, Stian Thorgersen <sthorger(a)redhat.com> wrote:
Adding my opinions on this
On 5 February 2018 at 13:01, Hynek Mlnarik <hmlnarik(a)redhat.com> wrote:
>
> Hi,
>
> please help me clarify the expected behaviour of brute force protection. I
> read the documentation [1] but I am still not 100% sure about it. I'm more
> after intention rather than actual implementation.
>
> 1) When should the Failure Reset Time apply? After the first or after last
> failed attempt?
Last failed attempt - it's safer this way
>
>
> 2) Should failed login attempts counter be cleared after the first
> successful login or only after failure reset time regardless of the
> successful login?
Only after failure rest time - If there's an ongoing targeted attack on a
specific account this is important, otherwise an attacker would get new
attempts every time the user authenticates (which could be predicted, for
instance 9am every day)
>
>
> 3) Should login failures be counted while the account is locked?
No - I don't think this has any impact on safety and would have negative
effects for the user (most users will type the password again to check)
>
>
> 4) Should unlocking account in admin console reset login failures counter?
Yes - would be good to have a way to show the count in the admin console
though
>
>
>
> In other words, what is expected behaviour of the following scenarios
> (questions are in items marked with Q ->)? I intentionally don't suggest
> any correct answer below myself.
>
> Setup:
> - Permanent lockout: Off
> - Max Lock time: 15 mins
> - Wait Time Increment: 1 min
> - Failure Reset Time: 30 mins
>
> = Scenario 1 =
> 1.1) User locks its account
> 1.2) Another 3 immediate failed login attempts while account is blocked
> *Q -> *1.3) Check that after (1 or 3?) minutes the account is unlocked
>
> = Scenario 2 =
> 2.1) User locks its account
> 2.2) Wait until account is unlocked (should be 1x Wait Time Increment)
> 2.3) Then do another one failed login attempt.
> *Q -> *2.4) Should the account be locked now or only after next Max Login
> Failures?
> *Q -> *2.5) Wait until account is unlocked (should be 1x or 2x Wait Time
> Increment?)
> 2.6) Then fail another one login attempt
> *Q -> *2.7) Wait until account is unlocked (should be 1x or 3x Wait Time
> Increment?)
> *Q -> *2.8) Wait Failure Reset Time (since first or last failed attempt?)
> 2.9) Validate that the user can again lock themselves out only after Max
> Login Failures failed login attempts.
>
> = Scenario 3 =
> 3.1) User locks its account
> 3.2) Another 20 failed immediate login attempts while account is blocked
> *Q -> *3.3) Check that after (1 or 15?) minutes the account is unlocked
> (Max Lock time is 15 mins)
>
> Thanks
>
> --Hynek
>
> [1]
>
>
http://www.keycloak.org/docs/latest/server_admin/index.html#password-gues...
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
Red Hat