Michael Ströder wrote:
> Michael Ströder wrote:
>> Howard Chu wrote:
>>> The text also states
>>> The practice of storing hashed passwords in userPassword violates
>>> Standard Track (RFC 4519) schema specifications and may hinder
>> In practice we all live very well with this for years. That's least of a
>> problem today.
>>> Anyone building operational procedures on something that violates the specs
>>> was asking for trouble. Users should be using ldappasswd, that's what
>> ldappasswd writes a hashed password to - tataa - attribute
>> I cannot see how this is different from using ldapadd/ldapmodify.
> Wrong, ldappasswd sends a PasswordModify exop to a server. The server may
> implement that exop in any implementation-specific manner, and there is no
> guarantee that the password a server uses is ever instantiated in any LDAP
> entry. There is no guarantee that setting a userPassword attribute using
> ldapadd/ldapmodify will ever do anything useful for any given LDAP user.
You're arguing based on what a LDAP server could do. I'm arguing based on what
OpenLDAP and other server implementations are doing for years.
ActiveDirectory is an obvious example invalidating your argument.
None of what you said in this thread is a real argument against
hash algos to the core. Still you did not answer why SHA-1 is in and SHA-2 is out.
At present there is no need to change anything in the core since SHA-2 support
can be dynamically loaded. Don't fix what isn't broken.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/