Standards may dictate that passwords should be stored in clear text but the initial question seemed to be "why am I getting encrypted passwords for the userPassword value". My guess would be that he has the server storing these values in crypt. I was pointing out more of a specific technical issue than a standards based issue but I am glad that other discussion is brought about from it, As far as interoperability and security I can see why crypt might be an issue. Storing in clear text the ACL should only allow self read-write for passwords. Therefore just browsing wouuld not work unless there are stray backup LDIF files hanging around unprotected. I think the "crypt" option described has the potential to get very hairy. There should be a better way. I am only pondering at this moment... I don't want to have to enter attributes for each value and type of crypt as a subtype of password. Unless the server was automatically doing this. Mark Wahl wrote: > > Isn't it a violation of RFC 2256 to have the value of the userPassword > > attribute encrypted in a way that is visible to the protocol? Or is my > > inexperience with LDAP showing? > > RFC 2256 states for the userPassword attribute: > > Passwords are stored using an Octet String syntax and are not > encrypted. > > An application which wishes to store an encrypted password SHOULD use an > attribute description distinct from "userPassword". Reusing userPassword > for another syntax without preserving its semantics would break > interoperability. One possible approach is to define a new attribute > type for each encryption mechanism, e.g. unixEncryptedPassword and > lanManEncryptedPassword. However, this approach would mean that an application > could not set a password even if it was protected by an TLS connection. > Another approach is to define an attribute subtype from userpassword, either > with a different type name or using an option, e.g., userPassword;crypt-lanman > and userPassword;crypt-unix. The "crypt" option would need to be > defined by an standards-track RFC to specify the desired behavior on a > modification, e.g. is each option treated independently, or does the server > itself ensure that correct password hashes are generated? > > Mark Wahl, Directory Product Architect > Innosoft International Inc.
begin: vcard fn: Peter Buonora n: Buonora;Peter org: Open Foundations email;internet: pbuonora@openfoundations.com title: President tel;work: 617-605-8952 note: Expert Netscape Engineers providing open scalable intranet, internet, extranet, and e-commerce solutions. x-mozilla-cpt: ;0 x-mozilla-html: TRUE version: 2.1 end: vcard
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature