Hi everyone. I just read this information. 14.4. Password Storage LDAP passwords are normally stored in the userPassword attribute. RFC4519 specifies that passwords are not stored in encrypted (or hashed) form. This allows a wide range of password-based authentication mechanisms, such as DIGEST-MD5 to be used. This is also the most interoperable storage scheme. However, it may be desirable to store a hash of password instead. slapd(8) supports a variety of storage schemes for the administrator to choose from. If it is not typical to store passwords in LDAP in hashed form. Then how are you supposed to bind to LDAP without transmitting the clear text password across the network? I understand that SSL and Kerberos will fix this problem, but what if a user just wants to use plain LDAP? Would I need to dictate to a customer that they must use a hash alg. in the userPassword in this case? thanks
On 7/6/10 11:44 PM, Bryan Boone wrote:
Hi everyone. I just read this information.
14.4. Password Storage LDAP passwords are normally stored in the userPassword attribute. RFC4519 specifies that passwords are not stored in encrypted (or hashed) form.
*encrypted*. Not encrypted *or* hashed.
Encrypted is really different from Hashed. Encryption means you have a way to decrypt the password. Hashing does not offer this possibility.
This allows a wide range of password-based authentication mechanisms, such as DIGEST-MD5 to be used. This is also the most interoperable storage scheme. However, it may be desirable to store a hash of password instead. slapd(8) supports a variety of storage schemes for the administrator to choose from.
If it is not typical to store passwords in LDAP in hashed form.
All the existing ldap servers support hashed passwords. Usually, the mechanism is stored in frm of the encrypted password like : {MD5}XXXXXXX or {crypt}YYYYYYYYY
Then how are you supposed to bind to LDAP without transmitting the clear text password across the network?
Even if the password is hashed ( you still have to pass the password in clear text ).
I understand that SSL and Kerberos will fix this problem, but what if a user just wants to use plain LDAP?
Ask this user his bank account number and his password... There is no reason for him to refuse to give you such information if he accepts the idea that his password will be transmitted in clear.
Hey, it's not like if this is a unsafe planet where some bad bad people are willing to use those information to spam or send scams. We are all living in a peaceful and honest world... ;)
Would I need to dictate to a customer that they must use a hash alg. in the userPassword in this case?
You just need to explain this customer the very basis of what is security.
Or may be point him to http://www.ietf.org/rfc/rfc4513.txt, 6.3.3. Password-Related Security Considerations :
"...The use of clear text passwords and other unprotected authentication credentials is strongly discouraged over open networks when the underlying transport service cannot guarantee confidentiality. LDAP implementations SHOULD NOT by default support authentication methods using clear text passwords and other unprotected authentication credentials unless the data on the session is protected using TLS or other data confidentiality and data integrity protection..."
On 06/07/10 14:44 -0700, Bryan Boone wrote:
Hi everyone. I just read this information. 14.4. Password Storage LDAP passwords are normally stored in the userPassword attribute. RFC4519 specifies that passwords are not stored in encrypted (or hashed) form. This allows a wide range of password-based authentication mechanisms, such as DIGEST-MD5 to be used. This is also the most interoperable storage scheme. However, it may be desirable to store a hash of password instead. slapd(8) supports a variety of storage schemes for the administrator to choose from.
If it is not typical to store passwords in LDAP in hashed form. Then how are you supposed to bind to LDAP without transmitting the clear text password across the network? I understand that SSL and Kerberos will fix this problem, but what if a user just wants to use plain LDAP? Would I need to dictate to a customer that they must use a hash alg. in the userPassword in this case?
I believe your question is based on a misinterpretation of the above. Storing the password in clear text within the userPassword attribute opens up several SASL based authentication mechanisms which do not transmit the password over the network, such as with DIGEST-MD5 (See RFC 2831).
Storing your password in a hashed form may restrict the ability of the server, or the SASL library, in making use of such mechanisms, and could allow, or even require, your users to transmit the password in clear text over the network.
Assuming that you only allow SASL binds, you can implement a configuration option of 'sasl-secprops minssf=64' to require users to choose authentication mechanisms that provides a security layer of at least 64 bits (for example). See RFC 4422.
Even when using such appropriate mechanisms to authenticate, it's still a good idea to protect the authentication handshake with TLS.
openldap-technical@openldap.org