Spring-security: SEC-3187: LdapUserDetailsManager password change with LDAP operation (RFC 3062)

[spring-issuemaster]

Mark Janssen (Migrated from SEC-3187) said:

Currently the LdapUserDetailsManager changePassword method modifies the password attribute directly. It would be better to (optionally) use the LDAP Password Modify Extended Operation as described in RFC 3062. This way, any associated attributes (e.g. Samba NTLM hashed passwords) will also be updated by the LDAP server.

[quanah]

This is a security issue, not just an improvement. By doing a direct modify on the userPassword attribute, the security configuration for userPassword is bypassed.

[kopax]

I have noticed some clear password stored in my test LDAP database because of that. Any update on this?

We use a bcrypt module on the Ldap and the BCryptPasswordEncoder hash is not compatible with the bcrypt hash. Only the SSHA password and weak password encryption are available.

It's clearly a security issue.

[carlspring]

Hi,

Is there any update on this?

[fuss86]

+1

[sbespalov]

+1

[carlspring]

@monowai,
Why the downvotes?

[jacovt]

+1

[jacovt]

This is raised when analyzing code through vulnerability analysis tools like Snyk:

https://snyk.io/vuln/SNYK-JAVA-ORGSPRINGFRAMEWORK-31644

[carlspring]

Yeah, we're getting it in our snyk.io reports as well!

Could we have an update on this, please?

[acooley]

+1. This needs to be fixed.

[steve-todorov]

Are there any updates on this? @tekul, @rwinch, @jgrandja ping?

[carlspring]

Is there any update on this? It's been around for a while now and it's causing our snyk.io checks to fail, (which is, of course the least of our concerns, given the seriousness of the issue). Could we get some sort of update, please?

[carlspring]

Thanks for fixing this @jzheaux ! In which version do you think this will be released and any idea when that will be? :)

[jzheaux]

@carlspring Looks like I failed to add the milestone earlier.

It's available in 4.2.9, 5.0.9, and 5.1.1, which are in Maven Central now.

[ddillard]

Is there any plan to get a CVE for this issue?

[rwinch]

@ddillard No. This was not a feature that was supported, so users would have been expected to hash it themselves.