openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#7326) [PATCH] use AI_ADDRCONFIG if defined in the environment
by quanah＠symas.com 19 Jul '19

19 Jul '19

This patch is rejected as it requires RedHat's custom version of glibc that has been patched to address issues like: <https://sourceware.org/bugzilla/show_bug.cgi?id=12398> <https://sourceware.org/bugzilla/show_bug.cgi?id=12377> In the future, I would ask that RedHat not submit patches that depend on custom RedHat implementations of core libraries. Thanks. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by ondra＠mistotebe.net 19 Jul '19

19 Jul '19

On Fri, Jul 19, 2019 at 11:45:02AM +0000, gv(a)members.scinet.supercomputing.org wrote: > On Thu, Jul 18, 2019 at 05:53:54PM -0400, Greg Veldman wrote: >> Would a default-off ifdef to activate that code block work for >> this? I did intentionally keep that part of the change self >> contained, so it wouldn't be hard to add that... > > Actually, re-reading RFC 6238 this morning (section 5.2, > especially paragraph 1), I believe this part of the proposed > change is both compliant and in accordance with recommended > practice in its current form. Yes, it makes sense to check the previous interval in case you entered the token just at the end of its validity even if you don't choose to test them in a broader window for resynchronisation (section 6). BTW, why did you choose to check that the user has already logged in rather than "(told == 0 || t - 1 > told)"? It might be better to check both the token and password independently and then return success iff both of them succeeded to avoid timing leaks of OTP success/failure? Sounds like a powerful oracle with PBKDF2 and similar hashes if you don't aggressively lock out users. Also probably needs to track the last successful OTP token somewhere else than the lastbind attribute even if the overall bind failed to mitigate the opposite attack. Also maybe use op->o_time instead of time(0L). Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by gv＠members.scinet.supercomputing.org 19 Jul '19

19 Jul '19

On Thu, Jul 18, 2019 at 05:53:54PM -0400, Greg Veldman wrote: > Would a default-off ifdef to activate that code block work for > this? I did intentionally keep that part of the change self > contained, so it wouldn't be hard to add that... Actually, re-reading RFC 6238 this morning (section 5.2, especially paragraph 1), I believe this part of the proposed change is both compliant and in accordance with recommended practice in its current form. -- Greg Veldman

1 0

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by gv＠members.scinet.supercomputing.org 18 Jul '19

18 Jul '19

On Thu, Jul 18, 2019 at 01:37:11PM -0700, Quanah Gibson-Mount wrote: > This should be a configuration item that is an integer value of the number > of seconds to allow outside of the timeslice, with 0 meaning only the > default time slice is allowed. Allowing people to authenticate outside of > the time slice is of course a security issue and should not be allowed by > default (So the default value of the parameter should be 0). I don't disagree, but by that logic so should the actual size of the time window, the number of digits, etc. I saw a lot of these parameters were hard-coded in this module and proceeded in kind. I wasn't really trying to recreate the full functionality of the OpenLDAP Gold implementation[1]. Would a default-off ifdef to activate that code block work for this? I did intentionally keep that part of the change self contained, so it wouldn't be hard to add that... [1] https://symas.com/two-factor-authentication-everywhere -- Greg Veldman IT Infrastructure Services, Purdue University gv(a)purdue.edu | (765)-496-2456

1 0

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by gv＠members.scinet.supercomputing.org 18 Jul '19

18 Jul '19

On Thu, Jul 18, 2019 at 08:32:22PM +0100, Howard Chu wrote: > it doesn't support setting > the password using the PasswordModify exop. That seems to imply that users are > required to generate their passwords using some other tool, and set them using a > normal Modify op, but doing so is deprecated. That is correct. > Password changes should only be done > using the PasswordModify exop. I wasn't sure how to do this. My implementation is essentially two password checks in one, so I need a way to tell the data apart. For the check functions this was easy as the OTP key is stored base32 encoded, and the DELIM character should not appear in a base32 string. For actual password input, I don't think I can make that assumption. I think the safest way to hash this scheme would be to have two separate input prompts, but I didn't see in the existing code a provision for this. It's possible I wasn't looking in the right places. If you have any suggestions I'd be happy to try writing that code. -- Greg Veldman IT Infrastructure Services, Purdue University gv(a)purdue.edu | (765)-496-2456

1 0

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by quanah＠symas.com 18 Jul '19

18 Jul '19

--On Thursday, July 18, 2019 7:37 PM +0000 gv(a)members.scinet.supercomputing.org wrote: > - Allow the OTP from the previous time window to be accepted, provided > there has been no successful bind in or after that time window. This > avoids false authentication failures if for example the time window rolls > over as the OTP is being entered or transmitted. This should be a configuration item that is an integer value of the number of seconds to allow outside of the timeslice, with 0 meaning only the default time slice is allowed. Allowing people to authenticate outside of the time slice is of course a security issue and should not be allowed by default (So the default value of the parameter should be 0). Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by hyc＠symas.com 18 Jul '19

18 Jul '19

gv(a)members.scinet.supercomputing.org wrote: > Full_Name: Greg Veldman > Version: HEAD > OS: CentOS 7 > URL: https://scinet.supercomputing.org/~gv/slapd-totp.txt > Submission from: (NULL) (128.210.189.74) > > > Improve the contrib/slapd-modules/passwd/totp module in the following ways: > > - Add support for two-factor (password+OTP) authentication, where password can > be defined via any currently-supported scheme. Your implementation of this feature is problematic, as it doesn't support setting the password using the PasswordModify exop. That seems to imply that users are required to generate their passwords using some other tool, and set them using a normal Modify op, but doing so is deprecated. Password changes should only be done using the PasswordModify exop. -- -- 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

(ITS#9055) contrib/slapd-modules/passwd/totp improvements
by gv＠members.scinet.supercomputing.org 18 Jul '19

18 Jul '19

Full_Name: Greg Veldman Version: HEAD OS: CentOS 7 URL: https://scinet.supercomputing.org/~gv/slapd-totp.txt Submission from: (NULL) (128.210.189.74) Improve the contrib/slapd-modules/passwd/totp module in the following ways: - Add support for two-factor (password+OTP) authentication, where password can be defined via any currently-supported scheme. - Allow the OTP from the previous time window to be accepted, provided there has been no successful bind in or after that time window. This avoids false authentication failures if for example the time window rolls over as the OTP is being entered or transmitted. The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Greg Veldman <gv(a)members.scinet.supercomputing.org>. I have not assigned rights and/or interest in this work to any party. I, Greg Veldman, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
by henrik.bohnenkamp＠ionos.com 18 Jul '19

18 Jul '19

On Mon, Jul 15, 2019 at 07:44:05PM +0100, Howard Chu wrote: > Howard Chu wrote: > > Henrik Bohnenkamp wrote: > >> On Mon, Jul 15, 2019 at 02:26:59PM +0100, Howard Chu wrote: > >>> > >>> Fyi, on our problematic test database with 11M entries and 3.7M aliases, a search with -a always , starting from the > >>> DB suffix, took 4 minutes without this patch, and 1235 minutes with this patch. > >>> > >>> Needless to say, that's not looking good. Still checking other test cases. I start to understand why this is the case. I believe that our two approaches to solve the problem each have their Nemesis... I have constructed a test case where the patched slapd needs 2 minutes (1 minute on a repeat) for a search for people objects, but the master branch has yet to finish after 30 minutes (and might not finish today). The test case is modeled similar to what is done in my company: group objects have not only member entries for people, but each member has an alias to the corresponding person object, these aliases being children to the respective group object. Furthermore, subgroups/group inclusion is modeled by adding aliases (also as children) to the group object, pointing to the group objects representing the included groups. So there is some recursive descent to get all person objects of all subgroups. In total I have 5 mio entries, 3 mio of which are aliases. There are no cycles, but in this test case the depth of the recursion is absolutely unrealistic. I believe, in the master-slapd, each step down in the recursion needs a call to mdb_idscope, which in turn goes through all 3 mio aliases to compute the intersection with the scope of the group object (that's what I remember, but I have not looked at the algorithm for a year now). The patch traverses in this case just very small sub-trees (although many of those) to collect the relevant aliases and continues from there. That seems to be much more efficient here. If I understand your description above correctly, my patch sucks with your test case because it does a full traversal of the LDAP tree to collect all aliases ... with 11 mio entries that takes a while. The master branch, however, just computes intersection with the scope once and continues from there, which must be much faster. I actually do not know what to conclude from all this. I wonder however, if a combination of both approaches could be beneficial. With the patch the diskNode of an entry contains not only the number of children in the scope, but also the number of aliases. If the total number of aliases in the database is large, but the search scope is small, the tree traversal might be faster. If the number of entries in the scope is big, and there are aliases in the search scope, the intersection in mdb_idscope might be more efficient. If there are no aliases in the search scope, nothing has to be done at all.

1 0

Re: (ITS#9054) Add support for multiple EECDH curves
by quanah＠symas.com 16 Jul '19

16 Jul '19

--On Tuesday, July 16, 2019 9:45 PM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.47 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.128.44) > > > Currently OpenLDAP only allows for a single EECDH curve to be configured. > However, OpenSSL 1.0.2 released in January 2015 was the first release to > implement negotiation of supported curves in TLS servers. OpenLDAP needs > updating to support this functionality. tls_dh.c in postfix/src/tls_dh.c gives some insight into how to correctly do this with OpenSSL, in the tls_auto_eecdh_curves fucntion. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

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