Reputation: 1560
I have this code authenticating my users against an LDAP directory. It returns false when there is an incorrect password, but if the password is left blank, it authenticates the user anyways. Any ideas why that might occur?
if (@ldap_bind($ds, $user_dn, $password) || sha1($password) == '484h84h4hf4Ffwj49393393j93j')
{
$valid = true;
}
else $valid = false;
Upvotes: 2
Views: 5680
Reputation: 1736
If you provide an empty password, then it indicates to the directory server that you are performing an anonymous simple bind. This behavior is described in RFC 2251 section 4.2.2:
If no authentication is to be performed, then the simple
authentication option MUST be chosen, and the password be of zero
length. (This is often done by LDAPv2 clients.) Typically the DN is
also of zero length.
This may be a pretty common security hole in LDAP clients because if they do not verify that the user provided a non-empty password but try to bind with a non-empty DN and an empty password then they can see that it succeeds, when the server didn't bind as the user specified by the provided DN but rather bound anonymously. Because this is such a common security problem in LDAP clients, some servers reject bind requests with a non-empty DN but an empty password, and this behavior is encouraged by the most recent LDAPv3 specifications, as indicated in RFC 4513 section 5.1.2:
An LDAP client may use the unauthenticated authentication mechanism
of the simple Bind method to establish an anonymous authorization
state by sending a Bind request with a name value (a distinguished
name in LDAP string form [RFC4514] of non-zero length) and specifying
the simple authentication choice containing a password value of zero
length.
The distinguished name value provided by the client is intended to be
used for trace (e.g., logging) purposes only. The value is not to be
authenticated or otherwise validated (including verification that the
DN refers to an existing directory object). The value is not to be
used (directly or indirectly) for authorization purposes.
Unauthenticated Bind operations can have significant security issues
(see Section 6.3.1). In particular, users intending to perform
Name/Password Authentication may inadvertently provide an empty
password and thus cause poorly implemented clients to request
Unauthenticated access. Clients SHOULD be implemented to require
user selection of the Unauthenticated Authentication Mechanism by
means other than user input of an empty password. Clients SHOULD
disallow an empty password input to a Name/Password Authentication
user interface. Additionally, Servers SHOULD by default fail
Unauthenticated Bind requests with a resultCode of
unwillingToPerform.
It sounds like your server doesn't do that. If it has the option to do that, then I would strongly recommend turning it on. But at any rate, a well-designed LDAP client that uses simple bind operations to verify user credentials should absolutely verify that the user provided a non-empty string before attempting to use it to bind to the server.
Upvotes: 8