[Date Prev][Date Next]
Re: Debugging a user authentication
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*...
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/