Michael Ströder wrote: > [email protected] 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 >>>> interoperability. >>> >>> 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 it's >>>> for. >>> >>> ??? >>> >>> ldappasswd writes a hashed password to - tataa - attribute 'userPassword'. >>> 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 adding SHA-2 > 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/
