Where does hashing take place with a webclient and LDAP

Question

We are currently implementing several web application that requires the user to create a user login that will be authenticated through LDAP calls. The LDAP server and user accounts will be shared by all the applications and the user's credentials will be the same across all applications.

My question is where does the hashing take place in a standard LDAP scenario, on the client side or does the LDAP server take care of it. It was my understanding that the LDAP server takes in a user password, at the time of creation, and hashes it and stores it. (By the by we plan on using salted SHA512 hashing and SSL connections between the client > webserver > LDAp server)

It was my understanding that the hashing operation takes place centrally on the LDAP server, relieving the client of the trouble and avoiding any breakage on the client end to affect other apps.

Answer 1

Modern, professional-quality servers use storage schemes for password attributes (usually userPassword and authPassword ) that involve executing the hash on the server. Servers usually append or prepend a unique value (called a salt) to a password, then execute the hash function. The "salt" minimizes the effectiveness of dictionary attacks, that is, dictionaries are more difficult to create for salted, hashed passwords.

SSL (a secure connection) should be used, or a non-secure connection should be promoted using the StartTLS extended request. An encrypted connection should be used so that passwords can be transmitted in the clear with BIND requests. Passwords that are transmitted in the clear over a secure connection can be checked for history and quality by the servers' password policy enforcement mechanisms. For servers that enforce password history and quality checks, passwords should not be transmitted pre-encoded. Therefore, it is not so much the "trouble" to the LDAP client as it is the fact that the server can enforcement organization-wide and agreed-to password quality and history checks in a central location.

see also

• LDAP: StartTLS request
• LDAP: Programming Practices