>From our testing it appears that slapd's usage of the crypt function, to check
a user's password on a bind request, is single threaded, rather than being
distributed across all of slapds thread. We encountered this problem when
bumping the number of hashing rounds for our password hashes from 5,00
Jesse Hathaway wrote:
From our testing it appears that slapd's usage of the crypt function, to check
a user's password on a bind request, is single threaded, rather than being
distributed across all of slapds thread. We encountered this problem when
bumping the number of hashing rounds for our p
On Fri, Feb 16, 2018 at 12:01:37PM -0600, Jesse Hathaway wrote:
#
{CRYPT}$6$rounds=1000$ykk4zGD3ODNR$iMP/zYeisoWTYgxLtPv1qzoo/dVrYQLAb9sKlRMBgPTfFrr9lTzEEkJ9NcFdGI/MiRxHSx/1x3rnw3RkNRMer/
# 'everyone loves butter'
Have you tested this using the native SHA-2 support (slapd-sha2 contrib
m
On Fri, Feb 16, 2018 at 12:54 PM, Howard Chu wrote:
> Depends entirely on whether or not your libc supports crypt_r() (reentrant
> crypt). If not then yes, it has to be single-threaded because crypt() is not
> reentrant, it returns a pointer to static storage.
>
> And of course, even if you use cr