--On Saturday, February 25, 2017 4:31 PM +1300 Andrew Bartlett
<abartlet(a)samba.org> wrote:
> When I asked notable Kiwi security researcher Peter Gutmann on the
> sidelines of Kiwicon about what to use if I ever imagined a Samba un-
> shackled from the restrictions of Windows compatibility (the printed
> conference program poked fun at AD for MD4), he strongly recommended
> Argon2 as mentioned in the link above.
>
> Either way, I'll follow this thread with interest, as I'm keen to have
> a password hash in Samba that is both best-of-breed and shared between
> modern OpenLDAP and Samba, for our administrators who need password
> sync.
There's actually an argon module that has been submitted for inclusion in
OpenLDAP (Via ITS#8575). So we may want to start with that.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
--On Friday, February 24, 2017 8:32 PM +0000 Howard Chu <hyc(a)symas.com>
wrote:
>> Yes, but there should be something stronger.
>>
>> How about moving ./contrib/slapd-modules/passwd/pbkdf2 to core?
>
> Yeah at this point we can probably bypass SHA2 and just go straight to
> SHA3. There's a lot of crypto software out there already using it. pbkdf2
> is still using SHA2.
Worthwhile to read over:
<https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016>
libsodium's a pretty trivial compile, I added it to Zimbra a while back for
another project.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
--On Friday, February 24, 2017 10:18 PM +0100 Michael Ströder
<michael(a)stroeder.com> wrote:
> Michael Ströder wrote:
>> I was referring to strength of password hashing scheme.
>
> And yes, I read your note about bcrypt. But I assumed that something
> which is already there and tested may be the most successful route for
> now.
We ship the bcrypt module as a part of the Symas build, and there are
others using it as well, per discussion on the OpenLDAP IRC channel. So
it's not untested. ;)
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
--On Friday, February 24, 2017 9:06 PM +0100 Michael Ströder
<michael(a)stroeder.com> wrote:
> Quanah Gibson-Mount wrote:
>> I think it would be wise to update OpenLDAP to a different default for
>> userPassword.
>
> Yes!
>
>> We currently have the Contrib SHA2 module,
>
> SHA-2 hashes with one round are also way too fast to be a good password
> hash algorithm.
>
>> It may be time to move the SHA2 module into core,
>
> Yes, but there should be something stronger.
Did you just skip entirely past the point where I said:
"but there has been some discussion of the limitations of the current SHA2
module in the past that would likely need addressing"
?? :)
The point of that sentence was to note that there are issues with the
current SSHA2 module that would need fixing prior to moving it to core.
And yes, perhaps PBKDF2 should be in core as well. ;)
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Michael Ströder wrote:
> Quanah Gibson-Mount wrote:
>> I think it would be wise to update OpenLDAP to a different default for userPassword.
>
> Yes!
>
>> We currently have the Contrib SHA2 module,
>
> SHA-2 hashes with one round are also way too fast to be a good password hash algorithm.
>
>> It may be time to move the SHA2 module into core,
>
> Yes, but there should be something stronger.
>
> How about moving ./contrib/slapd-modules/passwd/pbkdf2 to core?
Yeah at this point we can probably bypass SHA2 and just go straight to SHA3.
There's a lot of crypto software out there already using it. pbkdf2 is still
using SHA2.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
The general weakness of SHA has been understood for some time, although
progress advances on finding collisions (Such as
<https://security.googleblog.com/2017/02/announcing-first-sha1-collision.htm…>).
I think it would be wise to update OpenLDAP to a different default for
userPassword. We currently have the Contrib SHA2 module, and there's a
nice bcrypt(*) module on Github (I asked the author if they would be
willing to contribute it, but they seem to have gone silent).
It may be time to move the SHA2 module into core, but there has been some
discussion of the limitations of the current SHA2 module in the past that
would likely need addressing.
What do other folks think?
* <https://github.com/wclarie/openldap-bcrypt/issues/1>
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
The patch for ITS8529 has been pushed to OpenLDAP master. Generally I'd
push something like this to RE24 as well, except for the fact that it
results in a behavior change vs prior releases (at least if OpenLDAP is
linked to OpenSSL).
On the plus side, the patch reveals potential misconfigurations that were
previously not noted.
On the minus side, it could affect someone's existing deployment.
(Although that deployment would clearly be in error).
I personally think it would be best to apply it to RE24, particularly given
that it has security implications. I know Michael Stroeder already noted
he would like to see it in RE24 as well.
Does anyone have some good concrete reasons why it should not go into RE24?
Thanks,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
--On Friday, February 03, 2017 1:53 PM +0100 Dieter Klünter
<dieter(a)dkluenter.de> wrote:
> Am Wed, 01 Feb 2017 13:14:56 -0800
> schrieb Quanah Gibson-Mount <quanah(a)symas.com>:
>
>> For some reason, test061 routinely fails for back-mdb in HEAD. I've
>> not had luck reproducing the issue with other backends or in RE24.
>>
>> To eliminate it being a replication delay, I increased the for loop
>> to give 55 seconds time (1 through 10 seconds) chance to replicate.
>> Most of the time the test fails in fewer than 50 iterations (most
>> often fewer than 20), however one time it took as long as 85
>> iterations before failing.
> [...]
>
> I now have intensively tested this issue and found occurrences in all
> branches. Just some examples:
>
> ERROR: Entry 21 not replicated to ldap://localhost:9012/! (32)!
> Error found after 1 of 1 iterations
> Failed after 15 of 50 iterations
> [dieter@pink tests (OPENLDAP_REL_ENG_2_4=)]$
>
> ERROR: Entry 21 not replicated to ldap://localhost:9012/! (32)!
> Error found after 1 of 1 iterations
> Failed after 6 of 50 iterations
> [dieter@pink tests (OPENLDAP_REL_ENG_2_5=)]$
>
> I did about 100 test runs looping 50 times. In average every 7th
> testrun failed.
Interesting... I've had > 1000 passes and 0 failures in RE24.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>