Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Date: Thu, 11 Apr 2013 09:49:19 +0000 (UTC)
From: "Peter Hmelak (JIRA)" <jira@apache.org>
To: dev@directory.apache.org
Message-ID: <JIRA.12641898.1365622165361.148564.1365673759794@arcas>
In-Reply-To: <JIRA.12641898.1365622165361@arcas>
References: <JIRA.12641898.1365622165361@arcas>
Subject: [jira] [Commented] (DIRSERVER-1822) Same password can be used
 multiple times, when SSHA is used for password hash.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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