[
https://issues.apache.org/jira/browse/DIRSERVER-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215037#comment-17215037
]
Emmanuel Lécharny commented on DIRSERVER-2334:
----------------------------------------------
Hi Ryan,
I have had a quick look at the code, and it seems that you are right.
What should be done is storing the hashed value of the password in the history,
and we should compare the hashed value of the current password with the stored
hashed values. That also means we should grab the salt from each stored hashed
password to compute the hashed value of the provided password.
Not that complex to implement, IMO.
Also note that storing non hashed passwords in history is a security breach...
> 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: [email protected]
For additional commands, e-mail: [email protected]
