Hey zopeists - I've already sent a note to the DC guys about this, but they're all busy having fun at the Expo, so I thoungt I'd let the rest of you know, as well. I'v been using the USerDb unsupported product, and like it. However, I'v been bothered by seeing my users cleartext passwords in the db, so I added crypt hashed storage to the UserDb product. This will allow the use of unix 'passwd' style passwords (also used by apache for .htpasswd files) in the database. It also gives a modicum of security if you db backend is on a different machine from the Zope install, so the passwords don't travel around in the clear in the SQL queries. Of course, the biggest benfit is my not having to cringe when I see the bad passwords people chose in the database ;-) If anyone wants the patches, I can supply them. I assume it'll show up in the unsupported or contrib downloads at www.zope.org, once they get back. This requires the python crypt module. My Win32 install seems to have included it automagically. I had to copy the cryptmodule.so from my system python install into my Zope specific one to get in to work on Linux. Ross P.S. A useful script, for converting an exisiting sql db: as written, it takes a whitespace seperated file of username,password pairs and spits out sql statements to update the passwords (this version works with Postgresql: you may need to flavor by changing the ; or something to work with other dbs) from string import split,letters from crypt import crypt from whrandom import choice import fileinput for line in fileinput.input(): name,password=split(line) print "update users set password='%s' where username='%s';" % (crypt(password,choice(letters)+choice(letters)),name) -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005
In the daily section, in "Jon Corbet's first report" (top news item at the moment). Here's the blurb about Zope: I also saw a demo of Digital Creations' new Zope-based "portal toolkit." That is one slick system, chances are you'll start seeing sites based on this stuff popping up before too long. There is a whole set of facilities for discussions and such, while allowing the site owner to control just how much access each user is given. The new WebDAV and FTP modes make it much easier to edit Zope content - no longer are users restricted to using a browser window. Overall a very nice package. It's in an alpha testing mode now, with a general release to happen in early June. Digital Creations also had the first Zope 2.0 release, which adds a lot of new capabilities, and a number of long-awaited scalability features. --- John Eikenberry [jae@kavi.com - http://taos.kavi.com/~jae/] ______________________________________________________________ "A society that will trade a little liberty for a little order will deserve neither and lose both." --B. Franklin
"Ross J. Reedstrom" wrote:
Hey zopeists - I've already sent a note to the DC guys about this, but they're all busy having fun at the Expo, so I thoungt I'd let the rest of you know, as well. I'v been using the USerDb unsupported product, and like it. However, I'v been bothered by seeing my users cleartext passwords in the db, so I added crypt hashed storage to the UserDb product. This will allow the use of unix 'passwd' style passwords (also used by apache for .htpasswd files) in the database. It also gives a modicum of security if you db backend is on a different machine from the Zope install, so the passwords don't travel around in the clear in the SQL queries.
You mentioned problems, related to password storage, but seems, there are security problems in UserDb package, which are related to interaction between Zope and client browser: 1) "__ac" cookie, used in cookie-based authetication contains just base64-encoded string "<username>:<password>", and using such cookies is similar to transferring passwords through the net in plain-text form :-) Seems that it would be much better to use a kind of hash function as a cookie string (MD5 for example) 2) As I understood from the UserDB code, __ac cookie never expires (it is expired manually in some cases), just because it does not contain timestamp (either last hit or moment of cookie creation). So, as I see, the right solution may be the following: cookie must contain username and timestamp in plainext form (or base64encoded, does not matter) and hash function from "username:password:timestamp". -- Best regards Oleg Machulski ---------------------------------------------------- http://www.geocities.com/SiliconValley/Network/7671/ mailto:oleg_machulski@geocities.com
Oleg Machulski wrote: <snipped Oleg pointing out security problems with cookie authentication> I agree Oleg, that cookies aren't really any better than plain old basic authentication on the client<->server side. However, I see I failed to mention in that note what my set up is - I figured since I'd been spamming the list with my problems, everyone knew about them ;-) I'm running Zope under Apache-SSL, so the front side communications are all encrypted. The leak out the backend to the Db was my only exposure. Of course, fixing how Zope sets cookies and deals with passwords doesn't do much good if the client still sends a cleartext password at first login - there needs to be some client side support for some form of encryption on the password before it get's sent to the server for the very first time. Unfortunately, nothing beyond Basic Auth. seems to be standard, except full blown SSL, encrypting thre entire traffic stream (and it does slow things down). I suppose a Java applet would work, or perhaps even some really clever javascript? Eventually, this turns into a Diffie-Hellman key exchange sort of thing, doesn't it? Ross -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005
"Ross J. Reedstrom" wrote:
Oleg Machulski wrote: <snipped Oleg pointing out security problems with cookie authentication>
I agree Oleg, that cookies aren't really any better than plain old basic authentication on the client<->server side. However, I see I failed to mention in that note what my set up is - I figured since I'd been spamming the list with my problems, everyone knew about them ;-) I'm running Zope under Apache-SSL, so the front side communications are all encrypted.
But COOKIES are stored on the client-side in a plaintext file. hehe. :-) besides, adding expiration feature to authentication system rules.
The leak out the backend to the Db was my only exposure.
Of course, fixing how Zope sets cookies and deals with passwords doesn't do much good if the client still sends a cleartext password at first login - there needs to be some client side support for some form of encryption on the password before it get's sent to the server for the very first time. I beleive :-) that if we use SSL, it doesn't matter.
if https:// server could generate cookie for http://, then we could authenticate user on ssl host, generate complicated cookie, and then switch to non_SSL connection, but as far is I know, such tricks require special settings to be done in the browser setup, and these settings may lower security of the client.
Unfortunately, nothing beyond Basic Auth. seems to be standard, except full blown SSL, encrypting thre entire traffic stream (and it does slow things down). I suppose a Java applet would work, or perhaps even some really clever javascript? Eventually, this turns into a Diffie-Hellman key exchange sort of thing, doesn't it? Maybe, but using JavaScript seems to be insecure. Of course it does not affect server security, but lot of people prefere to have their JavaScript OFF.
So seems that the only possible solution is to maintain fully encrypted connections. -- Best regards Oleg Machulski ---------------------------------------------------- http://www.geocities.com/SiliconValley/Network/7671/ mailto:oleg_machulski@geocities.com
participants (4)
-
John Eikenberry -
Oleg Machulski -
reedstrmļ¼ wallace.ece.rice.edu -
Ross J. Reedstrom