Preflight Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for an issue that matches the one I want to file, without success.
• I am not looking for support or already pursued the available support channels without success.

Version

2.39.0

Storage Type

Kubernetes

Installation Type

Official Helm chart

Expected Behavior

It should accept my preexisting password and allow me to login as with 2.38.0

Actual Behavior

Failed login attempt for user: "<my-username>". Invalid credentials.

Steps To Reproduce

No response

Additional Information

My existing, randomly generated password happened to contain (at least) one of the characters now disallowed (or escaped) since the changes in #3372.

The first issue is that upgrading to 2.39.0 would force us to update our password policy on the LDAP server side to keep it in sync with these new requirements, and/or handle extra support from users when they for fairly non-transparent reasons fail to login using dex with passwords that work just fine elsewhere.

The second issue is that the change itself seems somewhat strange. Is it really, actually, necessary? Are the username and the password sent to conn.Bind() really used by the LDAP library in a way that can possibly be exploited through injection? Does the pull request solve an actual issue that someone saw somewhere?

In short: if it's not necessary, this change both reduces security by limiting the characters available for use in a password while it at the same time increases configuration and maintenance burden by introducing additional password requirements beyond those already configured on the LDAP server side.

Using randomly generated passwords with various symbols seems like a very common use-case to me, and I cannot imagine that I'll be the only one who will stumble upon this change :)

Configuration

No response

Logs

No response