hyc@symas.com 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.