Why can a simple bind with a valid DN but an empty password become a security hole?

LDAP treats "DN with empty password" as an unauthenticated bind, which succeeds as an anonymous session; an application that only checks "did the bind succeed?" then logs in anyone who leaves the password field empty.

RFC 4513 distinguishes three mechanisms of the simple bind:

• Anonymous: no name, no password.
• Unauthenticated: a name but no password. It exists mainly for logging/tracing purposes and results in an anonymous authorisation state, not in the named identity.
• Name/password: the real check.

The trap: a login page binds with the user's DN and the password the user typed. If the user types nothing, the server may answer "success" for the unauthenticated bind. Code that treats any successful bind as "password correct" now grants access without a password.

Defences are cheap and belong in every LDAP login integration:

1. Reject empty passwords in the application before binding.
2. Configure the server to refuse unauthenticated binds (RFC 4513 says servers should not allow them by default).

Go deeper:

• RFC 4513, Section 5.1.2: Unauthenticated mechanism — the definition and why clients should disallow empty passwords.
• RFC 4513, Section 6.3.1: Unauthenticated mechanism security considerations — the exact login-page scenario described above.