On 01/15/2014 09:38 AM, Richard Mixon wrote:
During the bind process is there anyway to tell 389 directory server
hash a plaintext password n (multiple) times before trying to compare to
what is stored?
I am trying to implement something similar to what's described in this
Our plan was to to use SSHA256 to hash the passwords around 200,000
times before storing. This would at least slow down any cracking
attempts should someone get access to our directory.
No, there is not a way to configure it to perform multiple hash
iterations. This would require a password storage scheme plug-in. This
is very similar to PBKDF2, which we have on a list of potential future
I've read through the documentation on the Red Hat Directory Server
site, including the "Plug-in Guide". Under "5.8 Checking Passwords"
refers to calling function "slapi_pw_find_sv()" - looking at the doc for
this function it does not look like hashing multiple times is supported.
Is there some means of doing this that is not obvious to me?
I can certainly do it by re-writing the security plugins for the various
servers (Tomcat, PHP Wordpress, etc) such that they hash the plaintext
password n minus 1 times before issuing the bind - but was hoping not to
If you are familiar with C coding, you could work on the above ticket to
implement a PBKDF2 plugin for 389 DS. We would be willing to get it
into the project since it's on our roadmap. Let me know if you are
interested in working on this, and I can provide you with some pointers.
I'm relatively new to 389 directory server, but so far quite happy to
have moved to it from another directory server.
Thank you - Richard
Custom Computer Creations, L.L.C.
mobile: (480) 577-6834 office: (480) 614-3442
email: rnmixon(a)CustCo.biz <mailto:rnmixon@CustCo.biz
Microsoft Partner ID: 1263725
The messages and documents transmitted with this notice contain
confidential information belonging to the sender. If you are not the
intended recipient of this information, you are hereby notified that any
disclosure, copying, distribution or use of the information is strictly
prohibited. If you have received this transmission in error, please
notify the sender immediately.
389 users mailing list