[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. 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. Well, you're the OpenLDAP god. So you can arbitrarly decide whatever you want. (But you shouldn't wonder why there's no active OpenLDAP community.) Ciao, Michael.
