Proposed proposals: password encryption, ZODB RAM
Here are a couple of ideas I'd like to toss out. Proposals can take a lot of time to write and it might be easier this way to flesh out the details. 1) Optional password encryption. Right now passwords are stored as clear text. What's interesting is that Zope can already authenticate against SHA encrypted passwords, it just won't encrypt user passwords unless you force it to. As a test of Zope's ability to authenticate against encrypted passwords, I sneakily implemented the "inituser" changes with SHA encryption by default. That means that the password for the initial user stored in the database is not possible to decrypt and yet nobody has had any problems with it AFAIK. Since it has been successful, I'd like to suggest we add a checkbox to basic user folders that enables encryption for new passwords, and have it turned on by default. The risk is incompatibility with HTTP digest auth, which I imagine nobody is using right now. 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. The only risk is the speed impact during loading of objects. Shane
On Mon, Jun 18, 2001 at 12:28:54PM -0400, Shane Hathaway wrote:
1) Optional password encryption. Right now passwords are stored as clear text. What's interesting is that Zope can already authenticate against SHA encrypted passwords, it just won't encrypt user passwords unless you force it to. As a test of Zope's ability to authenticate against encrypted passwords, I sneakily implemented the "inituser" changes with SHA encryption by default. That means that the password for the initial user stored in the database is not possible to decrypt and yet nobody has had any problems with it AFAIK. Since it has been successful, I'd like to suggest we add a checkbox to basic user folders that enables encryption for new passwords, and have it turned on by default. The risk is incompatibility with HTTP digest auth, which I imagine nobody is using right now.
There is already a proposal for this: http://dev.zope.org/Wikis/DevSite/Proposals/EncryptedUserfolderPasswords You could, of course, create a counter proposal.. -- Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ ---------------------------------------------
On Monday 18 June 2001 15:33, Martijn Pieters wrote:
On Mon, Jun 18, 2001 at 12:28:54PM -0400, Shane Hathaway wrote:
1) Optional password encryption. Right now passwords are stored as clear text. What's interesting is that Zope can already authenticate against SHA encrypted passwords, it just won't encrypt user passwords unless you force it to. As a test of Zope's ability to authenticate against encrypted passwords, I sneakily implemented the "inituser" changes with SHA encryption by default. That means that the password for the initial user stored in the database is not possible to decrypt and yet nobody has had any problems with it AFAIK. Since it has been successful, I'd like to suggest we add a checkbox to basic user folders that enables encryption for new passwords, and have it turned on by default. The risk is incompatibility with HTTP digest auth, which I imagine nobody is using right now.
There is already a proposal for this:
http://dev.zope.org/Wikis/DevSite/Proposals/EncryptedUserfolderPasswords
You could, of course, create a counter proposal..
I'm suggesting a checkbox that enables and disables encryption. Enabling encryption is actually very simple--I've had it enabled on my own box for nearly a year. :-) Shane
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 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 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 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. Toby Dickenson tdickenson@geminidataloggers.com
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
participants (3)
-
Martijn Pieters -
Shane Hathaway -
Toby Dickenson