[Zope-dev] Proposed proposals: password encryption, ZODB RAM

[Toby Dickenson]

On Mon, 18 Jun 2001 12:28:54 -0400, Shane Hathaway
<shane@digicool.com> wrote:

>1) Optional password encryption.  Right now passwords are stored as=20
>clear text.

I dont understand the advantage of this scheme as applied to Zope.

As long as basic authentication is used, a system administrator is
free to collect plain-text passwords, and I am assuming anyone who
cares about this topic will not be using basic authentication over
unencrypted http.


The small advantage I do see is that passwords can not be scrounged
through direct access to Data.fs. In the current situation we need to:
* restrict access to Data.fs on the live server
* store backup tapes securely (or encrypt content)
* encrypt Data.fs when copied to a backup server

However, I dont think encrypting user passwords is enough. Data.fs may
contain plaintext passwords for relational databases, and in many
cases it contains arbitrary confidential information.

Would it make more sense to encrypt whole storages?

>The risk is incompatibility with HTTP digest auth, which I=20
>imagine nobody is using right now.

And incompatability with almost all other not-yet-invented
authentication schemes.


>2) If cPickle were to do something similar to "intern"-ing strings when=20
>loading objects from the ZODB, Zope might consume significantly less=20
>RAM on busy servers.  ZODB uses lots of strings.  ZODB caches cannot be=20
>shared among threads. But strings, being immutable, can be safely=20
>shared. We couldn't just intern the strings since that would make them=20
>immortal, but if we used weak references it could work. =20

I like this alot.

Can the idea be extended to other objects which Zope treats as
immutable? For example, DTMLMethod objects hold a dtml parse tree made
up of cvlass instances. This must have a significant memory footprint.



Toby Dickenson
tdickenson@geminidataloggers.com