[keycloak-dev] argon2 password hashing
Roelof Naude
roelof.naude at gmail.com
Fri Apr 29 09:44:51 EDT 2016
nevermind. forgot to add the PasswordPolicySpi to the services file...
On Fri, Apr 29, 2016 at 2:48 PM, Roelof Naude <roelof.naude at gmail.com>
wrote:
> thank you, that helped.
>
> got the first round of changes done. some test cases are now failing.
> this is due to PasswordPolicy loading the PasswordPolicyProvider
> implementations. looks like the KeycloakSessionFactory::init was not
> called. factoriesMap is null.
>
> probably due to more setup / config needed. had a look at some of the
> provider tests (CustomIdentityProvider) but did not spot anything specific.
>
> do you have any hints?
>
> On 04/29/2016 11:10 AM, Stian Thorgersen wrote:
> > Pass in PasswordPolicy then. PasswordPolicy can store the config in the
> > correct format. getInt(String provider) would parse string and store as
> > an int in a map.
> >
> > This can be improved later, we're currently having a separate discussion
> > about adding something like this. Ideally password policies would also
> > support more advanced configuration like authenticators, mappers, etc
> > already do. That on the other side is more work. If you want to do
> > something like what they do that would be great though.
> >
> > On 29 April 2016 at 09:48, Roelof Naude <roelof.naude at gmail.com
> > <mailto:roelof.naude at gmail.com>> wrote:
> >
> > hi,
> >
> > adding the config to the verify / validate method makes no sense.
> > take for instance HashIterations. it needs to keep the config for
> > later when the password encode takes place. PasswordPolicy::validate
> > is called after construction of the policies...at a time when the
> > configuration has been parsed already. re-parsing the config for
> > every validate can be expensive.
> >
> > PasswordPolicyProvider implementations will most likely not access
> > external resources. granted, one cannot foresee all future usage
> > patterns either.
> >
> > On 04/29/2016 07:58 AM, Stian Thorgersen wrote:
> >
> > Simplest option is to simply add the config to the verify method.
> >
> > We have some other SPIs that have more than one instance of a
> given
> > provider per-realm, but as you say they're not associated with
> the
> > session. This could cause them not to be closed, or to have
> multiple
> > instances with same config created per-session.
> >
> > On 28 April 2016 at 15:37, Roelof Naude <roelof.naude at gmail.com
> > <mailto:roelof.naude at gmail.com>
> > <mailto:roelof.naude at gmail.com <mailto:roelof.naude at gmail.com>>>
> > wrote:
> >
> > thank you. have made some headway with this.
> >
> > there is a slight issue though. Providers are cached and
> > thus mostly
> > stateless.
> >
> > password policies on the other hand are constructed
> > on-demand and
> > may contain configuration. this configuration can be
> different
> > between various realms, e.g. HashIterations could be 20 for
> > realm1
> > and 200 for realm2.
> >
> > the current provider loading mechanisms caches both the
> > factory and
> > provider instances.
> >
> > 1. is there a session instance per realm? if so, then there
> > is no issue
> > 2. if not, how do you propose creating policy instances per
> > realm?
> >
> > PasswordPolicyFactory could expose an extra method,
> > create(String
> > arg), but the provider loading mechanism will ignore it.
> > one could
> > add specific knowledge of that method, but that feels wrong.
> >
> > another option would be to teach KeycloakSession to return a
> > ProviderFactory instance. PasswordPolicy could call this
> > method to
> > create PasswordPolicyProvider instances on-demand. this
> > method would
> > delegate to the underlying KeycloakSessonFactory to lookup
> the
> > appropriate factory.
> >
> > this last option could work. would prefer to clear it with
> > you guys
> > first though.
> >
> > On 04/28/2016 07:51 AM, Stian Thorgersen wrote:
> >
> > First thing would be to create PasswordPolicySPI,
> > PasswordPolicyProviderFactory
> > and PasswordPolicyProvider. PasswordPolicyProvider
> > should have same
> > methods as Policy. You'd then have to extract all
> > built-in providers
> > from PasswordPolicy into PasswordPolicyProvider
> > implementations,
> > this
> > should be relatively straightforward as they are
> > already "id" ->
> > implementation, just means you retrieve it with
> > KeycloakSession
> > rather
> > than hard-coded in PasswordPolicy. PasswordPolicy
> > should then be
> > change
> > to use KeycloakSession to retrieve
> > PasswordPolicyProvider instead of
> > hard-coded Policy implementations.
> >
> > Next step would be admin console integration. At the
> > moment the
> > list of
> > policies is hard-coded it would need to get the list of
> > policies
> > from
> > server-info instead. There are other bits that use
> > server-info
> > to list
> > providers already so take a look at that. You would
> > probably
> > also need
> > to add a method to PasswordPolicyProvider to return a
> > description of the
> > policy for the admin console tooltips.
> >
> > On 25 April 2016 at 18:36, Roelof Naude
> > <roelof.naude at gmail.com <mailto:roelof.naude at gmail.com>
> > <mailto:roelof.naude at gmail.com
> > <mailto:roelof.naude at gmail.com>>
> > <mailto:roelof.naude at gmail.com
> > <mailto:roelof.naude at gmail.com> <mailto:roelof.naude at gmail.com
> > <mailto:roelof.naude at gmail.com>>>>
> > wrote:
> >
> > thank you all for the quick response.
> >
> > do you guys have a basic idea on how to approach
> > the policy
> > spi? we
> > are more than willing to help out to get it done.
> >
> > maintaining a fork is maybe an option to resolve
> the
> > immediate need,
> > but would prefer to keep things upstream as much
> > as possible.
> >
> > On Mon, Apr 25, 2016 at 5:30 PM, Stian Thorgersen
> > <sthorger at redhat.com <mailto:sthorger at redhat.com>
> > <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>>
> > <mailto:sthorger at redhat.com
> > <mailto:sthorger at redhat.com> <mailto:sthorger at redhat.com
> > <mailto:sthorger at redhat.com>>>> wrote:
> >
> > We an to introduce a password policy spi soon,
> > but for now
> > you're stuck with the built-in policies.
> >
> > On 25 Apr 2016 16:43, "Bruno Oliveira"
> > <bruno at abstractj.org <mailto:bruno at abstractj.org>
> > <mailto:bruno at abstractj.org <mailto:bruno at abstractj.org>>
> > <mailto:bruno at abstractj.org
> > <mailto:bruno at abstractj.org>
> >
> > <mailto:bruno at abstractj.org
> > <mailto:bruno at abstractj.org>>>> wrote:
> >
> > I believe we don't have an SPI for this,
> > yet. See:
> > https://issues.jboss.org/browse/KEYCLOAK-2824.
> >
> > IMO, Argon2 is completely new and aside
> > from the
> > bindings,
> > we don't have
> > a Java implementation, yet for this. I'm
> > not sure
> > if is a
> > good idea to
> > introduce C to the codebase, but totally
> > doable to
> > have an
> > SPI for
> > policies.
> >
> > On 2016-04-25, Roelof Naude wrote:
> > > hi,
> > >
> > > a client has requested the use of the
> > argon2 [1, 2]
> > password hashing
> > > scheme. this can easily be added as an
> > external
> > provider.
> > we do however
> > > require custom password policies, e.g.
> > memory /
> > parallelism cost as well as
> > > salt length. AFAIK there is no way to
> > provide policy
> > extensions using a
> > > provider interface?
> > >
> > > would argon2 be a worthwhile
> contribution?
> > >
> > > regards
> > > roelof.
> > >
> > > [1]
> > https://github.com/P-H-C/phc-winner-argon2
> > > [2] https://github.com/phxql/argon2-jvm
> >
> > >
> > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > <mailto:keycloak-dev at lists.jboss.org>
> > <mailto:keycloak-dev at lists.jboss.org
> > <mailto:keycloak-dev at lists.jboss.org>>
> > <mailto:keycloak-dev at lists.jboss.org
> > <mailto:keycloak-dev at lists.jboss.org>
> > <mailto:keycloak-dev at lists.jboss.org
> > <mailto:keycloak-dev at lists.jboss.org>>>
> > >
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > <mailto:keycloak-dev at lists.jboss.org>
> > <mailto:keycloak-dev at lists.jboss.org
> > <mailto:keycloak-dev at lists.jboss.org>>
> > <mailto:keycloak-dev at lists.jboss.org
> > <mailto:keycloak-dev at lists.jboss.org>
> > <mailto:keycloak-dev at lists.jboss.org
> > <mailto: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160429/a60c7074/attachment-0001.html
More information about the keycloak-dev
mailing list