Nathan,

Sorry to respond so slowly. Thank you for the references. I was able to get through them and roughly see what's going on.

Unfortunately tooling up to do this is beyond what I can manage at this time - given workload and the fact we are relocating at the same time.

Thank you much - Richard.


On Fri, Jan 17, 2014 at 12:48 PM, Nathan Kinder <nkinder@redhat.com> wrote:
On 01/15/2014 10:51 AM, Richard Mixon wrote:
> Nathan/Rich,
>
> 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?

You can take a look at the existing password storage scheme plugin code:


https://git.fedorahosted.org/cgit/389/ds.git/tree/ldap/servers/plugins/pwdstorage

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

>
> Thank you - Richard
>
>
>
> On Wed, Jan 15, 2014 at 11:25 AM, Rich Megginson <rmeggins@redhat.com
> <mailto:rmeggins@redhat.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:
>>       http://www.stormpath.com/blog/strong-password-hashing-apache-shiro
>>
>>     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?
>
>     No.
>
>>
>>     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
>     https://fedorahosted.org/389/ticket/397?
>
>>
>>     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.
>>     mobile: (480) 577-6834 <tel:%28480%29%20577-6834> office: (480)
>>     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
>>     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@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>
>>     https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>     --
>     389 users mailing list
>     389-users@lists.fedoraproject.org
>     <mailto:389-users@lists.fedoraproject.org>
>     https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>
> --
> Richard Mixon
> Custom Computer Creations, L.L.C.
> mobile: (480) 577-6834 office: (480) 614-3442
> email: rnmixon@CustCo.biz <mailto: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@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users



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