Re: Debugging a user authentication

[Howard Chu <hyc@symas.com>]

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/