[keycloak-user] KEYCLOAK-4523 SPI implementation

[Adam Kaplan]

I noticed the ID for the original PasswordHashProvider
(Pbkdf2PasswordHashProvider) was hard-coded in several places.

1. Should I add an SPI definition to
default-server-subsys-config.properties?
2. Does calling getProvider(Class.class) on a KeycloakSession return the
default provider?

On Thu, Mar 9, 2017 at 12:15 PM, Adam Kaplan <akaplan at findyr.com> wrote:

> I'd agree with 4 being overkill - I just listed what was available in in
> the JRE.
>
> I started down the path of implementing - feature branch is here:
> https://github.com/adambkaplan/keycloak/tree/feature/KEYCLOAK-4523
>
> On Thu, Mar 9, 2017 at 8:24 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Search for usage of the class PasswordHashProvider
>>
>> On 9 March 2017 at 12:54, Ori Doolman <Ori.Doolman at amdocs.com> wrote:
>>
>>> From this discussion I understand that for all realm users, current
>>> password hashing algorithm is using SHA1 before the hashed password is
>>> saved to the DB.
>>>
>>> Can you please point me to the place in the code where this hashing
>>> occurs ?
>>>
>>> Thanks.
>>>
>>>
>>> -----Original Message-----
>>> From: keycloak-user-bounces at lists.jboss.org [mailto:
>>> keycloak-user-bounces at lists.jboss.org] On Behalf Of Bruno Oliveira
>>> Sent: יום ב 06 מרץ 2017 14:08
>>> To: stian at redhat.com; Adam Kaplan <akaplan at findyr.com>
>>> Cc: keycloak-user <keycloak-user at lists.jboss.org>
>>> Subject: Re: [keycloak-user] Submitted Feature: More Secure
>>> PassowrdHashProviders
>>>
>>> On Mon, Mar 6, 2017 at 8:37 AM Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>> > 4 new providers is surely a bit overkill? Isn't 256 and 512 more than
>>> > sufficient?
>>> >
>>>
>>> +1
>>>
>>>
>>> >
>>> > On 2 March 2017 at 15:28, Adam Kaplan <akaplan at findyr.com> wrote:
>>> >
>>> > This is now in the jboss JIRA:
>>> > https://issues.jboss.org/browse/KEYCLOAK-4523
>>> >
>>> > I intend to work on it over the next week or two and submit a PR.
>>> >
>>> > On Thu, Mar 2, 2017 at 4:39 AM, Bruno Oliveira <bruno at abstractj.org>
>>> > wrote:
>>> >
>>> > > Hi Adam and John, I understand your concern. Although, collisions
>>> > > are not practical for key derivation functions. There's a long
>>> > > discussion about this subject here[1].
>>> > >
>>> > > Anyways, you can file a Jira as a feature request. If you feel like
>>> > > you would like to attach a PR, better.
>>> > >
>>> > > [1] - http://comments.gmane.org/gmane.comp.security.phc/973
>>> > >
>>> > > On Wed, Mar 1, 2017 at 3:33 PM John D. Ament
>>> > > <john.d.ament at gmail.com>
>>> > > wrote:
>>> > >
>>> > >> I deal with similarly concerned customer bases.  I would be happy
>>> > >> to see some of these algorithms added.  +1
>>> > >>
>>> > >> On Wed, Mar 1, 2017 at 12:56 PM Adam Kaplan <akaplan at findyr.com>
>>> wrote:
>>> > >>
>>> > >> > My company has a client whose security prerequisites require us
>>> > >> > to
>>> > store
>>> > >> > passwords using SHA-2 or better for the hash (SHA-512 ideal).
>>> > >> > We're
>>> > >> looking
>>> > >> > to migrate our user management functions to Keycloak, and I
>>> > >> > noticed
>>> > that
>>> > >> > hashing with SHA-1 is only provider out of the box.
>>> > >> >
>>> > >> > I propose adding the following providers (and will be happy to
>>> > >> > contribute!), using the hash functions available in the Java 8
>>> > >> > runtime
>>> > >> > environment:
>>> > >> >
>>> > >> >    1. PBKDF2WithHmacSHA224
>>> > >> >    2. PBKDF2WithHmacSHA256
>>> > >> >    3. PBKDF2WithHmacSHA384
>>> > >> >    4. PBKDF2WithHmacSHA512
>>> > >> >
>>> > >> > I also propose marking the current Pbkdf2PasswordHashProvider as
>>> > >> > deprecated, now that a real SHA-1 hash collision has been
>>> > >> > published by Google Security.
>>> > >> >
>>> > >> > --
>>> > >> > *Adam Kaplan*
>>> > >> > Senior Engineer
>>> > >> > findyr <http://findyr.com/>
>>> >
>>> > >> > m 914.924.5186 <(914)%20924-5186> <(914)%20924-5186>
>>> > >> > <//914.924.5186
>>> > >> <(914)%20924-5186> <(914)%20924-5186>> | e
>>> >
>>> >
>>> > >> > akaplan at findyr.com
>>> > >> > WeWork c/o Findyr | 1460 Broadway | New York, NY 10036
>>> > >> > _______________________________________________
>>> > >> > keycloak-user mailing list
>>> > >> > keycloak-user at lists.jboss.org
>>> > >> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>> > >> >
>>> > >> _______________________________________________
>>> > >> keycloak-user mailing list
>>> > >> keycloak-user at lists.jboss.org
>>> > >> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>> > >>
>>> > >
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> >
>>> > *Adam Kaplan*
>>> > Senior Engineer
>>> > findyr <http://findyr.com/>
>>> >
>>> > m 914.924.5186 <//914.924.5186> | e akaplan at findyr.com
>>> >
>>> >
>>> > WeWork c/o Findyr | 1460 Broadway | New York, NY 10036
>>> > _______________________________________________
>>> > keycloak-user mailing list
>>> > keycloak-user at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>> >
>>> >
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>> This message and the information contained herein is proprietary and
>>> confidential and subject to the Amdocs policy statement,
>>>
>>> you may review at http://www.amdocs.com/email_disclaimer.asp
>>>
>>
>>
>
>
> --
> *Adam Kaplan*
> Senior Engineer
> findyr <http://findyr.com/>
> m 914.924.5186 <//914.924.5186> | e akaplan at findyr.com
> WeWork c/o Findyr | 1460 Broadway | New York, NY 10036
>



-- 
*Adam Kaplan*
Senior Engineer
findyr <http://findyr.com/>
m 914.924.5186 <//914.924.5186> | e akaplan at findyr.com
WeWork c/o Findyr | 1460 Broadway | New York, NY 10036