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

[Shane Hathaway]

On Tue, 19 Jun 2001, Toby Dickenson wrote:

> 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.

True.  The RDBMS passwords are probably more sensitive than user
passwords, and you certainly can't encrypt the RDBMS passwords.

> Would it make more sense to encrypt whole storages?

Probably not.  The idea is to encrypt them irreversibly, a scheme that
doesn't work for most other kinds of data.

> >The risk is incompatibility with HTTP digest auth, which I
> >imagine nobody is using right now.
>
> And incompatability with almost all other not-yet-invented
> authentication schemes.

What I had in mind, though, is that people would be allowed to turn off
encryption in the UI.  They would just have to then reset their passwords
to use the new authentication scheme.

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

Good idea.  I think such a thing could only be applied at the application
level (that is, DTMLMethod would have to be intimately aware of sharing).
It would be difficult to apply at the cPickle level.

Shane