On 01/15/2014 10:51 AM, Richard Mixon wrote:You can take a look at the existing password storage scheme plugin code:
> Thank you both for the responses.
> We are using the 389 Directory Server for a pretty isolated situation -
> authentication/authorization for external users on an "extranet" type
> portal website (it integrates pieces of several different web applications).
> We don't really envision (famous last words, I know) using it on a
> broader basis.
> Rich, I can understand why the pre-hashed passwords cause a lot of
> integration points to break. Is there a good alternative that still
> makes cracking your passwords prohibitively expensive?
> Nathan, I have a background in C, but do mostly Java these days. I will
> take a look at ticket 397 and get back to you if it's something I could
> work on. Can you provide me the pointers you were referring to?
Each storage scheme needs a set of comparison and encoding functions.
The comparison is used to validate a password during a bind operation,
and the encoding function is used when a password is set. You then
register these functions in pwd_init.c, which is where you can map the
storage scheme prefix with the callbacks.
The actual hashing would be done by calling into NSS from the new
> Thank you - Richard
> On Wed, Jan 15, 2014 at 11:25 AM, Rich Megginson <firstname.lastname@example.org
>> mobile: (480) 577-6834 <tel:%28480%29%20577-6834> office: (480)> <mailto:email@example.com>> wrote:
> On 01/15/2014 10:38 AM, Richard Mixon wrote:
>> During the bind process is there anyway to tell 389 directory
>> server to 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 article:
>> 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.
>> I've read through the documentation on the Red Hat Directory
>> Server site, including the "Plug-in Guide". Under "5.8 Checking
>> Passwords" it 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 do that.
> Use of pre-hashed passwords is strongly discouraged and will break
> things like sasl and replication.
> Does this have anything to do with
>> 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
>> Richard Mixon
>> Custom Computer Creations, L.L.C.
>> 614-3442 <tel:%28480%29%20614-3442>
>> email: rnmixon@CustCo.biz <mailto:rnmixon@CustCo.biz>
>> <mailto:rnmixon@CustCo.biz <mailto:rnmixon@CustCo.biz>>
>> Microsoft Partner ID: 1263725>> firstname.lastname@example.org <mailto:email@example.com>
>> 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
>> https://admin.fedoraproject.org/mailman/listinfo/389-users> <mailto:firstname.lastname@example.org>
> 389 users mailing list
> Richard Mixon
> Custom Computer Creations, L.L.C.
> mobile: (480) 577-6834 office: (480) 614-3442
> email: rnmixon@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
389 users mailing list