[ApacheDS] Password History Hashing

[Zachary Burke <za...@zacburke.com>]

[ApacheDS]

Hi All,
 
I'm working on a project here in work (written in Java) where we want to store our external users details in an LDAP database.
Initially I was looking at AD-LDS from microsoft, but things just were not transparent enough for me, to the point where I could
be happy with the solution from a security point of view. I like to understand the solution from end to end.
 
So I decided to use ApacheDirectory as its Open Source, LDAP compliant and from Apache. I downloaded the 2.0.0-M24 Release.
 
It was super easy to get working and configure the exact way I wanted it to work, starttls was a breeze and the password hashing / comparing
was done by Apache-DS. Got master 2 master replication to work as well which was awesome.
 
However, we have a requirement here where the user cannot change their password to any of their last 5 used passwords. Ok, thats configurable
via ApacheDS.
 
But I have noticed that ApacheDS, when storing the PasswordHistory details simply saves the password as encoded plain text, so any export 
of the ldap database would contain the users last N passwords encoded as base64 encoded plain text, under the attribute pwdHistory.
 
I notice that someone else has raised this issue as well.
 
https://issues.apache.org/jira/browse/DIRSERVER-2179 <https://issues.apache.org/jira/browse/DIRSERVER-2179>
 
So I was wondering two things.
 
1) If there is a password hashing interceptor enabled, is there a reason why you don't save off the hashed password into the history, and when checking to see if the password has been used before  perform a PasswordUtil.compareCredentials with the value from the password history object. Maybe there is something that I am not thinking about here.
 
2) As the code is all Open Source and I have it right here in front of me now :) , I was hoping to extend the Interceptor with my own and somehow try and over-ride  this behaviour where the password history object is saved as encoded plain text.
 
However the part where the password is set in the history is done within a private method in the AuthenticationInterceptor class
 
 
/**
  * Proceed with the Modification operation when the PasswordPolicy is activated.
  */
private void processPasswordPolicydModify( ModifyOperationContext modifyContext ) throws LdapException
  .....
  .....//ommited for breviety  
 
  PasswordHistory newPwdHist = new PasswordHistory( pwdChangedTime, newPassword );
  pwdHistoryAt.add( newPwdHist.getHistoryValue() );
  pwdAddHistMod = new DefaultModification( REPLACE_ATTRIBUTE, pwdHistoryAt );
 
So I guess that I would have to Over-ride quite a bit of the Interceptor, or make a full copy of the main AuthenticationInterceptor and change the relevant bits to fulfil my requirements.
 
Has anyone done any thinking about this before (ie) Adding this capability to the Interceptor for the password history ? , maybe in an old branch or something ? , or maybe its just something that has not been prioritised just yet.?
 
Would this be a recommended approach to implement my requirement ,(i.e) Over-ride quite a bit of the AuthenticationInterceptor class, or effectively cut and copy the AuthenticationInterceptor into my own class and change as I see fit. I’ve no problem in sharing this code back with the community.
 
Thanks a million.

-Zac Burke.
 
PS. Even though this represents a potential problem, I think it shows the power of an choosing an open source solution. 
One where I have all of the source code in front of me, to the extent that I can raise such issues with you, and while yes a cut and copy of the 
interceptor may not be the most elegant of solutions, I still can extend the functionality to fit.