[keycloak-user] Brut force attack questions

[Alexander Chriztopher]

nice !

is there a way to play with this via rest -regardless to wether am jpa,
infinispan or in-memory ?

On Wed, Nov 26, 2014 at 10:39 AM, Stian Thorgersen <stian at redhat.com> wrote:

> By default user sessions (and login failures) are stored in-memory not in
> the database. Unless you specify JPA for the userSession provider those
> tables will stay empty.
>
> You could either do what you're trying to do, which should work if you use
> the jpa userSession provider. The other if you're worried about the
> performance of storing user sessions in the db is to use the Infinispan
> provider, then you can manually delete login failures from the userSession
> cache from another application.
>
> We should add a mechanism to both view and remove login-failure entries to
> the admin console though.
>
> ----- Original Message -----
> > From: "Alexander Chriztopher" <alexander.chriztopher at gmail.com>
> > To: "Bill Burke" <bburke at redhat.com>, keycloak-user at lists.jboss.org
> > Sent: Wednesday, 26 November, 2014 9:45:42 AM
> > Subject: Re: [keycloak-user] Brut force attack questions
> >
> > Am to find a workaround in order to be able to unlock a user account. So
> far
> > i have tried to disable then enable the user account but this does not do
> > the trick apparently.
> >
> > I have also tried to tweek the database but it looks like the lock
> > information is not stored in the db even though there is the table :
> > USERNAME_LOGIN_FAILURE. Is it normal that this table stays empty even on
> > login failures ?
> >
> > Do you think of any other good workaround ?
> >
> >
> > On Tue, Nov 25, 2014 at 11:03 PM, Alexander Chriztopher <
> > alexander.chriztopher at gmail.com > wrote:
> >
> >
> > Nice ! Again, thank you.
> >
> >
> >
> > > On 25 Nov 2014, at 21:39, Bill Burke < bburke at redhat.com > wrote:
> > >
> > >
> > >
> > >> On 11/25/2014 3:27 PM, Alexander Chriztopher wrote:
> > >> Hi Bill and thanks.
> > >>
> > >> Do you think we will be able to have this within a short period of
> time
> > >> (4-6 weeks) or is it going to be planned for the long run ?
> > >
> > > Not sure on the priority of this. We have face to face meetings in a
> couple
> > > of weeks to discuss priority, then of course, its christmas vacation.
> > >
> > >> When is the value of max wait used as there is already a wait
> increment
> > >> out there ?
> > >
> > > Correct. It will increase the wait after each failure until the max is
> hit.
> > >
> > >>
> > >>
> > >>> On 25 Nov 2014, at 20:05, Bill Burke < bburke at redhat.com > wrote:
> > >>>
> > >>>
> > >>>
> > >>>> On 11/25/2014 12:32 PM, Alexander Chriztopher wrote:
> > >>>> Hi,
> > >>>>
> > >>>> I have a some question with regards to Brut Force Attack Protection
> :
> > >>>>
> > >>>> # 1 / When brut force attack protection is enabled is there a way to
> > >>>> know when a user account is locked ? I am thinking about the admin
> > >>>> console.
> > >>>>
> > >>>> # 2 / When a user account is locked is there a way to unlock it
> from the
> > >>>> admin console ?
> > >>>
> > >>> Unfortunately no for the above. I'll log a jira.
> > >>>
> > >>>> # 3 / What is the difference between wait increment (When failure
> > >>>> threshold has been met, how much time should the user be locked
> out?)
> > >>>> and max wait (Max time a user will be locked out.).
> > >>>
> > >>> correct on both.
> > >>>
> > >>>
> > >>> --
> > >>> Bill Burke
> > >>> JBoss, a division of Red Hat
> > >>> http://bill.burkecentral.com
> > >>> _______________________________________________
> > >>> keycloak-user mailing list
> > >>> keycloak-user at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >
> > > --
> > > Bill Burke
> > > JBoss, a division of Red Hat
> > > http://bill.burkecentral.com
> >
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141126/69a1e69a/attachment-0001.html