You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Ryan (Jira)" <ji...@apache.org> on 2020/10/14 21:54:00 UTC
[jira] [Commented] (DIRSERVER-2334) Password History Check broken
with SMD5 (Varied Salt Passwords)
[ https://issues.apache.org/jira/browse/DIRSERVER-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214296#comment-17214296 ]
Ryan commented on DIRSERVER-2334:
---------------------------------
The buildPwdHistory method referenced above is:
org.apache.directory.server.core.authn.AuthenticationInterceptor.buildPwdHistory
> Password History Check broken with SMD5 (Varied Salt Passwords)
> ---------------------------------------------------------------
>
> Key: DIRSERVER-2334
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2334
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: authn
> Affects Versions: 2.0.0-M22
> Environment: Java 8, Eclipse, Maven 3
> Reporter: Ryan
> Priority: Major
>
> I have the:
> Smd5PasswordHashingInterceptor
> added post the NormalizationInterceptor. Similar to this page:
> [https://directory.apache.org/apacheds/advanced-ug/6-implementing-interceptor.html]
> The problem is when the PasswordPolicyConfiguration.setPwdInHistory is enabled (set to five in this case), the buildPwdHistory method (line 1087), is doing a direct comparison of the history value bytes, this is not detecting previously typed identical passwords, in the history, because different salts were used to generate the stored password hash values.
> I believe, what needs to be done, is the non-hashed password 'password in the clear' needs to persist further down the interceptor pipeline so that this buildPwdHistory method can check the 'clear password' vs. the password history hashes, to detect previous usage, instead of trying to directly compare salted hashes.
> I am confident I could hack something together to fix this but I would be more obliged to contribute a patch back, if I could receive some guidance on where to store the 'clear password' state in the pipeline. I could envision an approach, where you keep this in the entity, and add a 'clear password' removal interceptor post the AuthenticationInterceptor.
> A temporary cache in the AbstractChangeOperationContext could also possible work.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org