RE: OpenLDAP / GUI client password compatibility: advice requested

["Betts, Chris" <Chris.Betts@ca.com>]

Excellent.  So in short, the whole idea of client hashing of
userPassword is slightly daft.  Correct JXplorer behaviour would be to
give the user the option of using an rfc3062 password modify extended
operation whenever the userPassword attribute value is changed,
including (presumably) on initial entry creation as a follow up step to
writing the rest of the user attributes.  If this is done, the server
will take whatever action it deems appropriate (updating external
password stores or hashing values for storeage or whatever).

A final question; should the use of this be a user option, or can the
client simply interrogate the server, discover whether the option is
supported (e.g. the passwdModifyOID value is present), and automatically
use it if it is supported?  

thanks for clearing this up,

   Chris


-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] 
Sent: Monday, 15 December 2003 10:59 AM
To: Betts, Chris
Cc: openldap-devel@OpenLDAP.org
Subject: Re: OpenLDAP / GUI client password compatibility: advice
requested


First, s/encrypt/hash/.

At 03:21 PM 12/14/2003, Betts, Chris wrote:
>    When an administrator creates a new user entry, or adds a 
>userPassword for the first time, the userPassword value is passed in as

>plain text - the server may (depending on configuration) 'encrypt' (one

>way hash really) the value locally.

No.  slapd(8) never encrypts/hashes userPassword values provided by the
user/admin (via LDAP Add/Modify Entry or via slapadd(8)). That would be
clearly violate the data model -- servers are required to preserve user
application data -- userPassword is a user applications attribute.

slapd(8) will, when configured to do so, hash passwords provided via the
LDAP Password Modify operation (RFC 3062) and store these values in
userPassword.  When this is done, it is wise not to expose userPassword
to user applications as user applications do not generally expect values
of userPassword to be encrypted/hashed (RFC 2256).

>    When a user binds using username/password, they enter their plain 
>text password - the server can then compute the 'encrypted' value for 
>the purpose of comparision.

Basically (but see below).

>    When the user or administrator *modifies* an existing userPassword 
>attribute, they need to encrypt(hash) it on the client.

No.  They should use the LDAP Password Modify operation to request the
server store the password per the server's policy. (The password may not
even end up in userPassword.)

>This modification is the *only* time that the client needs to encrypt 
>the value.

The client never needs to encrypt values.

>    If the client accidently encrypted the userPassword value on 
>binding, the bind would fail.

When the client is binding, it's not necessarily providing a value of
userPassword (or the value in which value(s) of userPassword were
derived), it is providing the user's password.  The user's password may
or may not be stored in the directory and, when so, may or may not be
stored in userPassword.  But, per standard, when so, it should be clear
text.  (Password schemes are a hack.)

>    If the client accidently encrypted the userPassword value on first 
>creation, later binds would fail.

Well, some servers might not actually support hashed userPassword, so a
client which stores a hashed value in userPassword might be quite
surprised to find a server which treat the hashed value as the password.

This is why clients should not hash password ever.  They should just use
Bind to bind and Password-Modify (RFC 3062) to modify passwords.

>    Is this correct?

See above.

>Or is there some other way the client should work?

See ldappasswd(1).

>JXplorer is a generic ldap/dsml browser that attempts to work well with

>all common ldap servers, and I want to make it easy for my users to 
>work well with openLDAP, so I'd like to avoid any misunderstandings, 
>which is why I haven't incorporated the patches I've been given quite 
>yet :-).
>
>    cheers,
>
>       Chris
>
>    
>Dr Christopher Betts
>Architect
>CA, Melbourne, Australia
>Dev Manager UDDI, DSML, JXplorer