[keycloak-dev] argon2 password hashing
Stian Thorgersen
sthorger at redhat.com
Fri Apr 29 01:58:24 EDT 2016
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> 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>> 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>> 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>> 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>
>> > 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>
>> 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/844f8a32/attachment.html
More information about the keycloak-dev
mailing list