<div dir="ltr">I think it could be useful that if a Keycloak is using an alternate hash (possibly insecure or sub-optimal), that it hashes the cleartext with ALT-HASH, and if successful, re-hashes the cleartext with KEYCLOAK-HASH and stores the new hash in the canonical Keycloak DB. This would allow for rolling migration of accounts as users login.<div><br></div><div>This way you could effectively rehash the passwords without forcing a global password reset. After so many days (90, 120, whatever your policy), you could determine who has not logged in successfully, by finding those who don't have a KC-stored password, and force them to reset upon next login or whatnot.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 5, 2015 at 1:08 PM, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yeah, for now, federation provider would be the correct approach. But<br>
if you're migrating we should provide a facility to plug in hash<br>
algorithm. I'll add a jira.<br>
<span class=""><br>
On 10/5/2015 11:59 AM, Remi Cartier wrote:<br>
> Hey guys,<br>
><br>
> I will have to migrate from a custom in house user management system to<br>
> keycloak.<br>
> We are using this algorithm to store salted/hashed password :<br>
><br>
> public static String hashPassword(String password, String salt) {<br>
> try {<br>
> KeySpec keySpec = new PBEKeySpec(password.toCharArray(),<br>
> salt.getBytes(), 2048, 160);<br>
> SecretKeyFactory secretKeyFactory =<br>
> SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");<br>
> byte[] hash =<br>
> secretKeyFactory.generateSecret(keySpec).getEncoded();<br>
> return new BigInteger(1, hash).toString(16);<br>
> } catch (Exception x) {<br>
> throw new IllegalStateException(x);<br>
> }<br>
> }<br>
><br>
> I was wondering, in order to ease the migration, if I could configure<br>
> keycloak to use the same hash algorithm ?<br>
><br>
> Or if there was any other ways ? Like maybe a federation provider, but<br>
> then comes the question when to push things into keycloak, at password<br>
> change ?<br>
><br>
> What do you think ?<br>
><br>
> Sincerely.<br>
><br>
</span>> ------------------------------------------------------------------------<br>
<span class="">><br>
><br>
> REMI CARTIER<br>
><br>
> B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner)<br>
><br>
</span>> *IMETRIK GLOBAL INC.*<br>
> *T :* <a href="tel:%2B1%20514%20448-6407%20x2009" value="+15144486407">+1 514 448-6407 x2009</a><br>
> *T :* <a href="tel:%2B1%20866%20276-5382" value="+18662765382">+1 866 276-5382</a> (toll free)<br>
> *F :* <a href="tel:%2B1%20514%20904-0611" value="+15149040611">+1 514 904-0611</a><br>
<span class="">><br>
> 740 Notre Dame St. West, Suite 1575<br>
> Montreal, Quebec, Canada H3C 3X6<br>
</span>> <a href="http://imetrik.com" rel="noreferrer" target="_blank">imetrik.com</a> <<a href="http://www.imetrik.com/" rel="noreferrer" target="_blank">http://www.imetrik.com/</a>><br>
><br>
><br>
><br>
> _______________________________________________<br>
> keycloak-user mailing list<br>
> <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
</font></span></blockquote></div><br></div>