Edit report at http://pear.php.net/bugs/bug.php?id=18420&edit=1
ID: 18420
Updated by: [email protected]
Reported By: chealer at gmail dot com
Summary: connect() option bindpw is not necessarily a password
Status: Closed
Type: Documentation Problem
Package: Net_LDAP2
Package Version: 2.0.11
PHP Version: 5.3.6
Assigned To: beni
Roadmap Versions:
New Comment:
> If there is a binddn, and one supplies an empty passwort, this should
only succeed, if the entry has no password set.
This is not true. I suppose I didn't make myself clear on the problem.
BTW, I am chealer on OFTC and PDPC if you want to discuss this.
Basically, what I should have clarified first is that the LDAP protocol
is ugly. What a modern protocol would do is provide a couple of bits to
specify if the request is for a normal bind, an anonymous bind or an
unauthenticated bind. An anonymous bind would take no extra info, an
unauthenticated bind would take a username and a normal bind would take
a username and password as usual. LDAPv3 has improved by at least
defining these concepts, but still folds this information in the
"username" and "password" fields. Presumably LDAP passwords cannot be
empty. Sending an empty "password" is the way to request an
unauthenticated bind (unless you're requesting an anonymous bind). See
http://tools.ietf.org/html/rfc4513#section-5.1.2
Thanks for the revision. I think r313689 is reasonable. However it could
be clearer. Instead of "An empty password", I would say "An empty bindpw
string", because bindpw is not *necessarily* a password.
Note typo "unathenticated".
Previous Comments:
------------------------------------------------------------------------
[2011-07-26 07:39:31] beni
-Status: Assigned
+Status: Closed
If there is a binddn, and one supplies an empty passwort, this should
only succeed, if the entry has no password set. That this can lead to
false security decisions in client applications is definitely a problem
of that application.
However, you are right, this should be documented. I fixed that now,
thanks for the reminder!
------------------------------------------------------------------------
[2011-07-26 00:22:20] chealer
-Status: Closed
+Status: Open
Hi,
thanks for the change, but if I'm seeing the change right, I don't
consider it fixes this issue. This is the description I'm currently
seeing on
http://pear.php.net/manual/en/package.networking.net-ldap2.connecting.php
:
Password for the binddn. If the credentials are wrong, the bind will
fail server-side and an anonymous bind will be established instead.
This still describes bindpw as a password for the binddn. But this is
not necessarily the case.
If the string is non-empty, bindpw is indeed considered as the password
for the binddn.
But, an empty strings instructs to attempt an unauthenticated bind,
unless binddn was also empty, in which case an anonymous bind is
attempted.
------------------------------------------------------------------------
[2011-07-18 14:59:17] beni
-Status: Verified
+Status: Closed
This bug has been fixed in SVN.
If this was a documentation problem, the fix will appear on pear.php.net
by the end of next Sunday (CET).
If this was a problem with the pear.php.net website, the change should
be live shortly.
Otherwise, the fix will appear in the package's next release.
Thank you for the report and for helping us make PEAR better.
------------------------------------------------------------------------
[2011-04-04 06:33:13] beni
-Status: Open
+Status: Verified
-Assigned To:
+Assigned To: beni
Hello, you are right. This definitely needs enhanced documentation.
------------------------------------------------------------------------
[2011-04-02 23:35:41] chealer
Description:
------------
The description of the bindpw option for connect() is inexact. It
reads:
Password for the binddn
In fact bindpw can also be the empty string if one wants to request
unauthenticated (or anonymous) authentication.
This is more than an undocumented feature. By taking an empty bindpw and
sending it raw to an LDAP server, Net_LDAP2 is requesting
unauthenticated authentification, which is not what one would expect
from the current documentation. This can cause critical security issues.
See http://tools.ietf.org/html/rfc4513#section-6.3.1 on this issue.
------------------------------------------------------------------------
--
Edit this bug report at http://pear.php.net/bugs/bug.php?id=18420&edit=1
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.