openldap-devel

openldap-devel@openldap.org

1416 discussions

ldif API
by Brett Sheffield 13 Mar '17

13 Mar '17

Greetings all, I'm new to the list. I'm told I should be asking my questions here (thanks Gavin). One of my programs[1] uses the as yet un-released LDIF API (ldap_parse_ldif_record() and friends), which presently means installing from openldap master. This was originally pulled in to master back in April 2010, but unfortunately hasn't made it into a stable release yet, which makes using it rather painful for those of us that do. Which leads me to ask three questions: 1) Am I correct in thinking this will make it into the 2.5 release? 2) Is there a rough release date planned for 2.5? 3) I've submitted my first patch to openldap[2], adding a new function ldif_open_mem() which is useful when working with ldif data in memory. I read through the contribution guidelines and I think I've made all the necessary copyright statements etc., but please let me know if I've missed anything. It would be great if this made it into 2.5 as well (tis a small patch). Cheers, Brett [1] https://github.com/brettsheffield/libgladdb [2] http://www.OpenLDAP.org/its/index.cgi?findid=8603 -- __________________________________________________________ Application Hosting | Virtual Servers | Monitoring | Email Tel: 0131 510 0340 http://www.gladserv.com/

1 0

Argon2 Password Hashing
by Simon Levermann 08 Mar '17

08 Mar '17

Hello, as discussed in https://www.openldap.org/its/index.cgi/Incoming?id=8575;selectid=8575, I'm currently working on making my argon2 password hashing module also work with libsodium instead of just the argon2 reference implementation. In the progress, a few questions came up: 1) Libsodium doesn't expose all of the same parameters to argon2 that the original implementation exposes. In Libsodium, we can only configure the memory and CPU cost, while argon2 also allows configuring the salt length (fixed 16bytes in libsodium), the hash length (fixed 32bytes in libsodium), and the parallelism (fixed 1 thread in libsodium). So the question is: Do we want to expose these when using the argon2 backend, or do we not want to expose them at all, offering a more unified "API"? Personally, I think these parameters are sane and don't really need to be configurable (as opposed to the work factors, which SHOULD be configurable) 2) Libsodium exposes an API for random-number-generation. Should I use this API for generating the salt when using argon2, or should I always use the openldap-builtin lutil_entropy? 3) Regarding configurability: Is there a guide available that shows how to add configuration parameters to a module? In my current configuration, the memory and CPU cost factors are hardcoded into the module, but making these configurable for users is desirable, since they can potentially raise security based on the amount of Users vs amount of processing power they have. Best regards, Simon Levermann

2 4

Re: scrypt ASICs - litecoin N, r, p settings - Re: Revisiting the SHA1 default password hash
by Emily Backes 07 Mar '17

07 Mar '17

> Requiring 1GB for a password hash will preclude using it on small devices, > e.g. raspberry pi. > > Even 16MB is excessive. It's sounding like the newer and more complicated hashes have a lot of configurable features that may need site-local tuning. Should these be part of e.g. slapd.conf config or be settings embedded in the value format for later clarity, like {HASHNAME:attr=val,attr=val,attr=val}SnVzdCBhbiBleGFtcGxlLCBzaWxseQ== Considering the size of some of these newfangled hashes, attribute length doesn't look to be a relevant concern any longer. Realistically this would probably be a better way to express things like salt values in addition to the iteration counts and so on. If a structured value is what we really want there, BER might be more appropriate, possibly with a leading {EXTENDED-STRUCTURE} hash declaration. -- Emily Backes Symas Corporation ebackes(a)symas.com

3 3

Re: scrypt ASICs - litecoin N, r, p settings - Re: Revisiting the SHA1 default password hash
by Howard Chu 07 Mar '17

07 Mar '17

Lorenzo M. Catucci wrote: > Just to add some context to Howard Chu's message from Sat, 25 Feb 2017, > I'd like to point out that the scrypt settings chosen for litecoin PoW, > which I think are the ones commercial mining hardware are optimized for, are > some orders of magnitude different than the ones recommended for user > authentication, and are not, in my humble opinion, a sufficient reason to > exclude the scrypt construct from consideration: > > - https://litecoin.info/Scrypt > uses N = 1024, r = 1, p = 1 > which means using > 1024 * 1 * 1 * 128 = 128 KiBytes bytes of memory > and doing > 2 * (1024 * 1) = 2 Ki hashing rounds > > - the traditional default values for the parameters are > N = 16384, r = 8, p = 1 , which means using > 2^16 * 8 * 1 * 128 = 16 MiBytes of memory > and doing > 32Ki hashing rounds > > and these values can be customized (almost) at will to increase both the > computational effort and the memory footprint of the password hashing; e.g. > libsodium's crypto_pwhash_scryptsalsa208sha256 sets N = 2^20 in the > "{OPS,MEM}LIMIT_SENSITIVE" case, leading to a memory occupation of 1GiB and > an hashing rounds count of 2 * 2^20. Requiring 1GB for a password hash will preclude using it on small devices, e.g. raspberry pi. Even 16MB is excessive. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: Argon2 Password Hashing
by Howard Chu 07 Mar '17

07 Mar '17

Simon Levermann wrote: > 2) Libsodium exposes an API for random-number-generation. Should I use > this API for generating the salt when using argon2, or should I always > use the openldap-builtin lutil_entropy? Salts are not sensitive data, they're always stored in the clear anyway. The only property they're required to have is to be unique among a given population of users/passwords. lutil_entropy is preferable just for uniformity, but it's not really critical. You could use anything, as long as you're not using something like this https://www.xkcd.com/221/ . -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

scrypt ASICs - litecoin N, r, p settings - Re: Revisiting the SHA1 default password hash
by Lorenzo M. Catucci 06 Mar '17

06 Mar '17

Just to add some context to Howard Chu's message from Sat, 25 Feb 2017, I'd like to point out that the scrypt settings chosen for litecoin PoW, which I think are the ones commercial mining hardware are optimized for, are some orders of magnitude different than the ones recommended for user authentication, and are not, in my humble opinion, a sufficient reason to exclude the scrypt construct from consideration: - https://litecoin.info/Scrypt uses N = 1024, r = 1, p = 1 which means using 1024 * 1 * 1 * 128 = 128 KiBytes bytes of memory and doing 2 * (1024 * 1) = 2 Ki hashing rounds - the traditional default values for the parameters are N = 16384, r = 8, p = 1 , which means using 2^16 * 8 * 1 * 128 = 16 MiBytes of memory and doing 32Ki hashing rounds and these values can be customized (almost) at will to increase both the computational effort and the memory footprint of the password hashing; e.g. libsodium's crypto_pwhash_scryptsalsa208sha256 sets N = 2^20 in the "{OPS,MEM}LIMIT_SENSITIVE" case, leading to a memory occupation of 1GiB and an hashing rounds count of 2 * 2^20. As for using SHA-3 defined PRFs for password hashing, while I'm not aware of any memory-hard construction based on sha-3/shake{128,256} it should be possible to define a pbkdf2 construction based on the KMAC construct from NIST Special Publication 800-185 instead of the HMAC one, but this seems a little bit premature, since the only implementation of KMAC I've found is the one added to https://github.com/gvanas/KeccakCodePackage 5 days ago with the "Added a draft implementation of KMAC (SP 800-185 standard)" commit. Best of all, yours lorenzo m catucci

1 0

Re: Revisiting the SHA1 default password hash
by Quanah Gibson-Mount 03 Mar '17

03 Mar '17

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

1 0

Re: Revisiting the SHA1 default password hash
by Quanah Gibson-Mount 24 Feb '17

24 Feb '17

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

3 2

Re: Revisiting the SHA1 default password hash
by Quanah Gibson-Mount 24 Feb '17

24 Feb '17

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

1 0

Re: Revisiting the SHA1 default password hash
by Quanah Gibson-Mount 24 Feb '17

24 Feb '17

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

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel