[keycloak-user] Submitted Feature: More Secure PassowrdHashProviders

[Ori Doolman]

>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