Re: [keycloak-user] Submitted Feature: More Secure PassowrdHashProviders

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(a)lists.jboss.org [mailto:keycloak-user-bounces@ lists.jboss.org] On Behalf Of Bruno Oliveira Sent: יום ב 06 מרץ 2017 14:08 To: stian(a)redhat.com; Adam Kaplan <akaplan(a)findyr.com&gt; Cc: keycloak-user <keycloak-user(a)lists.jboss.org&gt; Subject: Re: [keycloak-user] Submitted Feature: More Secure PassowrdHashProviders On Mon, Mar 6, 2017 at 8:37 AM Stian Thorgersen <sthorger(a)redhat.com&gt; 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(a)findyr.com&gt; 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(a)abstractj.org&gt; > 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(a)gmail.com&gt; > > 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(a)findyr.com&gt; 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(a)findyr.com > >> > WeWork c/o Findyr | 1460 Broadway | New York, NY 10036 > >> > _______________________________________________ > >> > keycloak-user mailing list > >> > keycloak-user(a)lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/keycloak-user > >> > > >> _______________________________________________ > >> keycloak-user mailing list > >> keycloak-user(a)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(a)findyr.com > > > WeWork c/o Findyr | 1460 Broadway | New York, NY 10036 > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > _______________________________________________ keycloak-user mailing list keycloak-user(a)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