RE: Encrypting attributes of my choice

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: James Bourne [mailto: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

That is a completely different question, and the answer is yes, OpenLDAP
does have support for special treatment of the userPassword attribute.
Technically speaking, this is not encryption, this is hashing. To use this
feature your client must use an LDAPv3 Extended Operation, the Modify-Passwd
operation. This operation accepts a cleartext password as input and stores
a hash of the cleartext in the userPassword attribute of an entry.

The difference between "encryption" and "hashing" is significant - in the
latter case, there is no expectation of reversability, and there are no keys
to manage. As such, it is trivial to implement hashing securely with minimal
administration overhead.

The problem with supporting reversible encryption inside the directory
itself
is that you then must manage the encryption keys, and they need to be both
securely protected and yet easily accessible to the server if they're going
to be used automatically. Once you do that, it's only one step removed from
no encryption at all. Think clearly about this, what are you trying to
defend
against by encrypting your directory data? If you're concerned that someone
can hack into your system and steal records out of your database files, then
automated encryption in the directory is still no defense. Any key that is
easily accessible to slapd will also be easily accessible to anyone with
direct
access to your database files. If you are using a product that supports
simple,
automatic data encryption for LDAP database entries, you have bought into
marketing hype, not real security.

The only way to store securely encrypted data in *any* data store is to do
so
in such a way that the means of encrypting/decrypting the data are kept
separate (far away!) from the data store. The burden of responsibility for
maintaining data security rests squarely with the generator and consumer of
the data, it cannot be placed on the repository.

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