[keycloak-dev] Brute force protection behaviour

[Bruno Oliveira]

Answers inline, but please keep in mind that some of them are my point
of view.

On 2018-02-06, Stian Thorgersen wrote:
> Adding my opinions on this
> 
> On 5 February 2018 at 13:01, Hynek Mlnarik <hmlnarik at 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
+1

> 
> 
> >
> > 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 reset 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)
+1

> 
> 
> >
> > 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)

I don't think it has a huge impact on safety, but I disagree here. If
you stop counting, as KC admin you can't tell which accounts are 
being targeted. But this is just my personal opinion.

> 
> 
> >
> > 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
+1
> 
> 
> >
> >
> > 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

>From my understanding it should be incremented at every attempt after
the account was locked, in your scenario 3 min.
> >
> > = 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?

IMO only after next Max Login Failure.

> > *Q -> *2.5) Wait until account is unlocked (should be 1x or 2x Wait Time
> > Increment?)

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?)

3x wait time increment. IMO we should give the KC admin time to respond
to such attack. 

> > *Q -> *2.8) Wait Failure Reset Time (since first or last failed attempt?)

Makes more sense to me after the 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)

I believe you meant "Max Wait". I'd say 15 min after the last failure.

> >
> > Thanks
> >
> > --Hynek
> >
> > [1]
> > http://www.keycloak.org/docs/latest/server_admin/index.
> > html#password-guess-brute-force-attacks
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-- 

abstractj