Hallvard B Furuseth wrote:
Andrew Findlay writes:
(1): The latest LDAP spec introduced pwprep to solve this problem, but hardly anything implements it yet. It will be many years before you can depend on common LDAP clients doing itproperly.
It's not just a client-side issue. Most sites store a password hash in their server rather than the cleartext password. That means the client needs to encode password with the same character encoding and preparation as whatever hashed the server-side password. (E.g. the /etc/passwd program.) Or the server needs to prepare cleartext passwords it receives from the client the same way, but it's likely a bad idea for the server to e.g. assume client passwords are latin-1 and convert to UTF-8.
userPassword is an octetString, therefore if the server does any type of character set conversion on its values it is Broken.
Clients should not do any hashing or encoding; they should use the PasswordModify exop and send a plaintext octetString. IMO it is not the LDAP subsystem's job to worry about how that octetString was generated. E.g., if you're using a device whose input mechanism (keyboard, touchscreen, whatever) can only generate 7 bit ASCII characters, that's not our concern. If your password was originally selected using 8 bit data, and your current keyboard cannot generate the relevant octets, you're SOL.
userPassword is a string of *octets* not *characters*...