directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zachary Burke <>
Subject [ApacheDS] Password History Hashing
Date Thu, 10 Aug 2017 15:24:27 GMT

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. <>
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.

View raw message