[
https://issues.apache.org/jira/browse/DIRSERVER-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628796#comment-13628796
]
Peter Hmelak commented on DIRSERVER-1822:
-----------------------------------------
Well correct me if I'm wrong, but I do believe that majority of enterprise
users do not use ldap clients (that would send hashed password) to change their
passwords. Actually I believe none do.
Instead they use the use web applications, that then sends plain-text password
via secure connection to ldap server, where server side hook hashes the
password.
So my preposition above should be able to work.
I still consider allowing same password as in history to pass trough
constraint, just because salt is used, as a bug.
> Same password can be used multiple times, when SSHA is used for password hash.
> ------------------------------------------------------------------------------
>
> Key: DIRSERVER-1822
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1822
> Project: Directory ApacheDS
> Issue Type: Bug
> Reporter: Peter Hmelak
> Assignee: Kiran Ayyagari
>
> When using SSHA (salted SHA) for password hashing, no CONSTRAINT_VIOLATION
> (invalid reuse of password present in password history) is thrown, if new
> password is the same as one already in pwdHistory.
> I believe current implementation just compares new password hash, with with
> ones stored in pwdHistory.
> And because of new salt, no two hashes are ever a-like, even though passwords
> are the same.
> Suggestion for fix:
> *Every* salt stored in pwdHistory should be used, together with new password
> when creating password hashes, that are then compared with ones already
> stored in pwdHistory.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira