[Zope-DB] Plaintext Password Concerns

[Jim Penny]

On Thu, May 15, 2003 at 06:35:24PM -0400, David A. Riggs wrote:
> On Thu, 2003-05-15 at 16:40, Jim Penny wrote:
> > On Thu, May 15, 2003 at 04:00:41PM -0400, David A. Riggs wrote:
> > > Our University would like to give out Zope accounts for
> > > groups of students so they may experiment and work on
> > > various projects. One key feature that people would like
> > > to use is connectivity to a PostgreSQL database.
> > > 
> > > We take security very seriously and would like some way
> > > around storing plaintext passwords in the connection
> > > strings for the Psycopg Database Connectors. Has anyone
> > > come up with some alternative to this or a solution to
> > > this possible security hazard?
> > > 
> > Two Answers:
> > 
> > 1)  It is OK that users share the connections to postgresql.
> > 
> >   put the pyscopgda in the root of your Zopes, and build a separate
> >   folder for each user.   Do not allow them to view root.  That should
> >   be enough.
> > 
> > 2)  Each user gets a separate database and thus requires a separate
> >     connection.
> > 
> >   Build a separate folder for each user.  Put the database connector in
> >   that folder.  Deny the user the right to view this folder.  Now put
> >   another folder, say sandbox inside the user's folder.  grant the user
> >   admin rights to this folder.  Use rewrite rules so that 
> >   http://host/userid is remapped to http://host/userid/sandbox.
> >   This should be plenty.
> 
> 
> Number 1 is most definitely out of the question, and number 2 addresses
> the wrong problem...we don't want other users to see a user's password.
> Let me try and explain the situation a bit better.

Number 2 does not address the wrong problem; at least for
non-administrators.  No non-administrator can see the connector,
not even the user himself.  But, in light of your further
information, it does not keep things in sync with the LDAP.  And it does
not protect users from administrators.

> 
> Zope authentication is performed against an OpenLDAP directory with
> LDAPUserFolder. LDAP people are mapped directly to Zope users, LDAP
> groups are mapped to Zope roles. PostgreSQL also authenticates against
> LDAP, every user has their own database in the PostgreSQL instance.
> We want to be able to give users their own folder in Zope where they
> can muck around and create applications, but not all users (just the
> members of a certain ZopeUsers LDAP group or something similar). The
> security hazard here is that Managers at a higher level in the Zope
> tree can view the plaintext password in their DB connectors (making
> things worse is that they are authenticating against the same source
> for everything, LDAP).
> 
> I'm trying to find some solution where this password isn't available
> plaintext for Managers higher in the Zope tree or people in this
> same sibling group.
> 
> What I want to be able to say is "bind to the database with the 
> username and pass of the object owner" rather than "bind to the 
> database with this explicit username and pass", though I may be
> seeking for answers in the wrong place.
> 
> 
> David A. Riggs
> lukewarm@ultrasoul.com
> West Virginia University CS/EE

I have no answer then.  But you need to give this some real thought.

I think that you have two basic choices.  Build a separate zope
instance for each user.  Or, modify your favorite connector to use LDAP to
get the password.

You are still going to have some problems - mostly due to zope spinning
off 4 database connection threads per adapter, at creation time and 
with the threads bound to a (database, user).  This means that, 
in your scheme, you are pretty clearly going to need an adapter per 
user, and that most of them are going to be sucking up connections 
without any activity.

I have seen some people in the past that have talked about trying to
write a lazy db adapter that did not bind until usage.  As far as I
know, nothing ever came of this.  It is pretty much against the grain of
the python db-api, and is apt to be pretty slow, especially against a
slowish connection-model db like postgresql (or oracle).  

Jim