openldap-devel

openldap-devel@openldap.org

1418 discussions

Re: openldap.git branch master updated. e12ca8b6fed6b8a2526c5c8ee820bf5aa942b59d
by Hallvard Breien Furuseth 15 Mar '17

15 Mar '17

On 15. mars 2017 12:15, openldap-commit2devel(a)OpenLDAP.org wrote: > commit e12ca8b6fed6b8a2526c5c8ee820bf5aa942b59d > Author: Howard Chu <hyc(a)openldap.org> > Date: Wed Mar 15 11:13:09 2017 +0000 > > Fixes for multiple threadpool queues > > Remove poolq_hash, it wasn't distributing work evenly to the queues. Not surprising when it was hashing the address instead of contents of a local variable. Whatever that intended to achieve, it looks to me like rand_r() would have done the same but better. (Also the hash was pointlessly slow in that it walked a byte at a time, it could have hashed better with fewer operations.) I guess I should have looked closer at that code earlier:-) -- Hallvard

1 0

Re: ldif API
by Quanah Gibson-Mount 13 Mar '17

13 Mar '17

--On Monday, March 13, 2017 7:46 PM +0000 Brett Sheffield <brett(a)gladserv.com> wrote: Hi Brett, > Which leads me to ask three questions: > > 1) Am I correct in thinking this will make it into the 2.5 release? Yes, it's already in the RE25 development branch. > 2) Is there a rough release date planned for 2.5? Not at this time. We had been planning on doing an initial alpha for 2.5 to get the ball rolling on sunsetting 2.4. I'd still like to get to that point, but we need to get the current 2.4 release stable first (Things like ITS#8444, ITS#8609, ITS#8589, ITS#8559, ITS#8545, ITS#8436, ITS#8528, ITS#8125, etc). There are also a couple of items that need fixing in master/RE25 before we do a 2.5 alpha as well. > 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 Great, thanks! I can't say when it will be responded to as it'll need a code review, most likely from Howard, and I know he's currently heavily involved in a customer project for Symas. The simple fact is, the project needs more active participants, particularly knowledgable C programmers, so that things do not continually back up waiting on Howard for a response to even get somewhere on them. :/ --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

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 08 Mar '17

08 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 08 Mar '17

08 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 25 Feb '17

25 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel