openldap-devel

openldap-devel@openldap.org

1420 discussions

Re: Storing TLS credentials in the directory
by Turbo Fredriksson 09 Apr '17

09 Apr '17

On 9 Apr 2017, at 04:06, Howard Chu <hyc(a)symas.com> wrote: > It's clear that nobody in the standards organizations considers storing private keys in the directory to be a safe thing to do. IMO this is just a matter of password security and good ACLs, and the standards should not preclude the option. It is no worse than storing userPassword. I agree (fwiw). It needs to be stored SOMEWHERE. Usually it’s in/on the filesystem. And the only two (?) things that protect it there is: 1) The access permissions on the file. I.e., “ACLs". 2) No/limited users allowed on the system. I.e., "password security" (?) So using “ACLs" and "password security" on the filesystem or in the directory, shouldn’t be that different. Only difference might be that the local FS isn’t available _outside_ the host, a directory is.

1 0

Re: openldap.git branch master updated. e12ca8b6fed6b8a2526c5c8ee820bf5aa942b59d
by Howard Chu 15 Mar '17

15 Mar '17

Hallvard Breien Furuseth wrote: > 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. It was hashing the bytes of arg. In the common case of the slapd_daemon_task submitting jobs to the pool, arg was the socket descriptor of an active connection, so this was always distributing those evenly. But in other cases where arg was a context pointer, the result was heavily skewed. > (Also the > hash was pointlessly slow in that it walked a byte at a time, it > could have hashed better with fewer operations.) for a 4 or 8 byte arg this was hardly important. > I guess I should have looked closer at that code earlier:-) -- -- 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: 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 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

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