A lot of backstory, but the main question is: Why can't we login after implementing secure passwords over LDAP over STARTTLS, but when we changed it to SSL/TLS we can? Beforehand, we could login, and we did not change the encryption.

Our setup: For a small non-profit NGO, we run a website (PHP 7.2) including a subdomain for our volunteers. Of course, volunteers have to have an account and login. For storage of relevant files for volunteers, we have a Synology NAS setup (and a backup, of course). To make sure volunteers are able to use the same account for both the NAS and our website, the NAS has an LDAP Directory Server setup, which functions as the provider server. When a volunteer logs in on the website, the credentials are checked with the LDAP. Also, there are options to change passwords and the like, all the normal stuff you'd expect.

When a user changes their password on the website, it would get changed in the LDAP server via ldap_mod_replace(), so the user is able to login at both places with the same credentials. So far, so good.

Our actions: When changing the password via the 'DSM' (Disk Station Manager, the proprietary software of the Synology NAS), it automatically gets salted and hashed using SHA-512. However, we found out that when changing it via PHP (with ldap_mod_replace() ), it just gets stored in plaintext. Obviously, a risk we were not willing to take.

To mitigate this, we've written code to salt and hash in PHP before replacing it, so the end result should be the same as changing it via Synology. It seemed as if Bcrypt for example was not available so we still used SHA-512. To make sure every user would have hashed passwords, we automatically generated random passwords, hashed those and replaced current passwords, and made everybody change their passwords. Inconvenient but necessary.

The problem: After doing so, all passwords were succesfully changed to random new passwords. Login on the website still worked, and with admin-accounts we could still login via software like Apache Directory Studio. However, when we tried to login via the DSM, we got errors that our username or password was invalid. Even when we changed passwords using the DSM, we still got the same errors. Even when we inserted plaintext passwords again, we still could not login.

The solution: After trying a lot of things, the solution turned out to be quite simple. The LDAP client* on the NAS had to have the encryption set to SSL/TLS instead of STARTTLS which it had been before. After that, we could login again. This solution was more of a lucky strike than a well thought out plan.

* Client, in this case, because the NAS runs an LDAP provider but a client as well, for login and directories.

The question: Any idea what caused this, and why this solution worked? We did not change any settings in either the LDAP server or the LDAP client, we only changed the passwords. As far as we know, this should have had any effects on the encryption used for connecting. If anybody has any idea, we'd like to hear them! It works now, but why is a complete mystery to us.

Also, please let me know if this isn't the right place to ask this!

migrated from webmasters.stackexchange.com Jul 4 at 0:17

This question came from our site for pro webmasters.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.