RE: Encrypting attributes of my choice

[James Bourne <jbourne@MtRoyal.AB.CA>]

On Thu, 7 Feb 2002, Howard Chu wrote:

> There is no facility in the code to encrypt specific attributes. This
> should be managed by your application.
>

Howard, Kurt, and all,
I would just like to put in here a note.

Many closed source applications which unfortunately do not encrypt data (and
won't encrypt data at any time in the future) within the application before
sending it to LDAP, are the problem.

I know that for example, userPassword should not be encrypted (by the RFC)
but, we use encrypted userPassword fields and do not allow openLDAP to bind
when an unencrypted userPassword field exists.  The reason is simple, we
want to make sure that there is as little chance as possible of this data
becoming compromised (we are authenticating many UNIX and web systems to the
database, and it would utterly be a nightmare if it happened).

How difficult would it be in the 2.0 head to provide this support, only to
be turned on with a configuration option in slapd.conf, thus offering
encrypted password storage support, or the strict RFC compliance?  Best of
both worlds?  Why is there resistance to this?  What would be the better
solution?

Other LDAP servers do this, why not this one as well?

Regards
James Bourne

>   -- Howard Chu
>   Chief Architect, Symas Corp.       Director, Highland Sun
>   http://www.symas.com               http://highlandsun.com/hyc
>   Symas: Premier OpenSource Development and Support
>

-- 
James Bourne, Supervisor Data Centre Operations
Mount Royal College, Calgary, AB, CA
www.mtroyal.ab.ca

******************************************************************************
This communication is intended for the use of the recipient to which it is
addressed, and may contain confidential, personal, and or privileged
information. Please contact the sender immediately if you are not the
intended recipient of this communication, and do not copy, distribute, or
take action relying on it. Any communication received in error, or
subsequent reply, should be deleted or destroyed.
******************************************************************************