[keycloak-dev] argon2 password hashing
Roelof Naude
roelof.naude at gmail.com
Fri Apr 29 03:48:05 EDT 2016
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>> 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>>>
> 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>>> 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>>> 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>>
> >
> 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>>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
More information about the keycloak-dev
mailing list