Howard Chu wrote: > Michael Ströder wrote: >> Howard Chu wrote: >>> Hashed userPassword values are strictly a server-internal implementation >>> detail, clients never need to know about them. >> >> Not true. >> >> 1. E.g. think of bulk sync processes where it's quite usual that you convert >> password hashes within the LDAP client - in some cases even salted. > > If you can convert from one hash to another, the hash is broken.
Conversion in this context means converting string representations of (salted) hashes. Obviously the algorithm and order of password and salt has to be the same. >> 3. In some cases it's more appropriate that a LDAP client writes several >> attributes in a *single* LDAP write operation instead of using a add/modify >> with a subsequent Password Modify ext. op. E.g. when subschema has 'MUST >> userPassword' for an object class used. > > Perhaps so. But this requires the client (or admin running the client) to > already know what schemes the target server supports. We all know that clients have to use some a priori knowledge - most times called protocol. ;-) Another use-cases is dealing with data migration to server product of another vendor. => So I consider this draft to be useful. > Finally, an objectclass that defines "MUST userPassword" also has to be > considered broken. (Reminds me of groupOfNames / MUST member.) That's simply your personal opinion not a strong objecting argument. >> userpasswordvalue = cleartext-password / prefix hashed-password > > I think you should replace "hashed-password" with "scheme-specific data" and > stop there. That's a conclusion of your opinion. But I want to describe the *order* of password and salt used by any server I saw using the scheme. > Provide examples for MD5/SHA/SHA-2 if you like, but emphasize that > these are just informal examples. The whole I-D has target "informational". > There's no reason someone can't come along > and use an unconstrained octet string after the scheme, if they really want > to. Yes. But this would just be another scheme to be defined somewhere else. This draft does not claim to cover everything you could ever stuff into 'userPassword'. Ciao, Michael.
smime.p7s
Description: S/MIME Cryptographic Signature
