[keycloak-dev] rehash password if different algorithm?

[Marek Posolda]

On 03/08/16 00:45, Bill Burke wrote:
> Hey,
>
> Ran into something implementing a user federation example.  My user
> federation example stores passwords in plain text.  So, I wrote a plain
> text password hasher. The first time the password is validated, the
> hashing iterations don't match from the returned
> UserCredentialValueModel.  The user fed provider always returns 0
> because its plain text.  The CredentialValidation class sees that the
> hash iterations dont' match with the default realm's hashing iterations,
> so the password is rehashed.  Rehashed with the default realm
> algorithm.  There is a bug here in that the algorithm is not set to the
> realm's hashing algorithm, so, once a user is validated once, they can
> never be validated again...at least in this scenario.
I assume it works this way, for case that the old passwords are imported 
from some legacy storage into Keycloak DB. Those passwords might be 
hashed with some weak algorithm or they might be just in plain-text. So 
after successful validation of plain-text password is the stored 
plain-text password dropped and new password credential is created and 
saved again into Keycloak DB with the official realm algorithm (pbkdf2 + 
20000 iterations).
>
> The bigger question is, how do we handle this scenario where the User
> Federation Provider does not store passwords in the same format as the
> realm's password policy? The workaround is to ignore password updates
> when updateCredentialsDirectly is called.  But this seems like a hack.
> A lot of documentation would need to be in place for this.
I think that some 3rd party federation SPI are able to store the 
password credential with all the info, but some others are limited.

For example if you want to update password to LDAP , you need to send it 
in plain-text. Not send hash + salt + requested hash algorithm. Same if 
you want to validate password against LDAP, you need to use plain-text. 
In other words, credential storage SPI must be able to use 
UserCredentialModel instead of UserCredentialValueModel.

Not sure if credential SPI storage should support both possibilities? 
Either possibility to store plain-text password or full 
UserCredentialValueModel or both? And have some switch what exactly it 
supports?

Previously the UserFederationProvider.validCredentials was supposed to 
always receive password in plain-text. The stuff like 
CredentialValidation.validPassword was supposed to be invoked just for 
validating against our JPA or Mongo, but not against 3rd party 
UserFederationProviders.

Marek
>
> Bill
>
> _______________________________________________
> keycloak-dev mailing list
> 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/20160803/a30c1f1c/attachment.html