Michael Ströder wrote:
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.
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.
-
hyc＠symas.com