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
up)
--
Cheers,
Jeremy
