On 09/08/17 15:19, Mike Brudenell via Exim-users wrote:
>    - Supply a valid username and valid password: Authentication succeeds
>    - Supply a valid username and invalid password: Authentication fails
>    with "535 Incorrect authentication data"
>    - Supply an invalid username and a password: Authentication fails with
>    "435 Unable to authenticate at present"

> But with the third the log shows
> failed to bind the LDAP connection to server ldap.york.ac.uk:389 - LDAP
> error 32: No such object
> This does cause an expansion error which then, as documented, causes
> server_condition to instead defer with the 435 SMTP response. For this the
> LDAP error is "LDAP error 32: No such object"
> Maybe the latter isn't being handled properly and so causing the expansion
> failure rather than returning a false failure?

It's explicitly how it's coded.

> From a security point of view, surely it's not good to return different
> responses if the username exists/doesn't exist? It gives an attacker a way
> of discovering what usernames actually exist so can then focus on their
> password. (cf. The "Invalid username or password" generic login failure
> messages.)

You could argue that it's a specification, or design, bug.  I'm not sure
we'd want to change how it works though, at least as default.  Possibly
an option for different behaviour.

Possible workaround, then: check explicitly for a valid username
before checking the password?

(It is possible to code a test for a "defer" explicitly in ACLs, but
it's a trifle complex.  If you prefer that route, ask and I'll look it

## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Reply via email to