May 1999 - Zope - Zope lists

RE: [Zope] Security glitch on user-editing form
by Rob Page 11 May '99

11 May '99

> Great; I'm sorry I wasn't aware of this. No prob... "I just work here" and am unaware of a lot of things in Zope. :^) > Question: Do you need a module for NT authentication, or are > you writing > this already? (In case you need contributions.) That _must_ be a rhetorical question! Of course, we'd __**LOVE**__ a contributed NTUserFolder! When can we have it? -- only half-kidding! Tks, --Rob

1 0

RE: [Zope] Security glitch on user-editing form
by Alexander Staubo 11 May '99

11 May '99

Great; I'm sorry I wasn't aware of this. Question: Do you need a module for NT authentication, or are you writing this already? (In case you need contributions.) Alexander Staubo http://www.mop.no/~alex/ mailto:redhand@mop.no >-----Original Message----- >From: zope-admin(a)zope.org [mailto:zope-admin@zope.org]On Behalf Of Rob >Page >Sent: 11. mai 1999 22:54 >To: 'Alexander Staubo' >Cc: 'zope(a)zope.org' >Subject: RE: [Zope] Security glitch on user-editing form > > >> Any one-way encryption method will work, but why not modularized >> authentication support? Something that would permit you to >> use anything > >Already there in user folders! :^) We happen to have implemented an >internal Zope authentication/authorization database. Additionally, at: > >http://www.zope.org/Download/Unsupported > >there's an etcUserFolder (auth against /etc/passwd type files) and a >UserDB (auth against an RDBMS) and sometime soon there might be an >LDAPUserFolder based on something that smells a lot like an LDAP >Database Adapter. > >> from one-way-encryption to Kerberos to LDAP, but not >> necessarily just a >> fixed algorithm. LDAP is an interesting possibility, but I >don't like >> the idea of being stapled to LDAP -- it's overkill for most >> installations. > >I agree totally! My _real_ question was, in the internal User Folder >component, whether to store passwords a) in their original form or b) >as a hash or c) as a selectable option ... Of course, the c) is >probably the best answer! > >--Rob > >_______________________________________________ >Zope maillist - Zope(a)zope.org >http://www.zope.org/mailman/listinfo/zope > >(For developer-specific issues, use the companion list, >zope-dev(a)zope.org - http://www.zope.org/mailman/listinfo/zope-dev ) >

1 0

RE: [Zope] Security glitch on user-editing form
by Rob Page 11 May '99

11 May '99

> Any one-way encryption method will work, but why not modularized > authentication support? Something that would permit you to > use anything Already there in user folders! :^) We happen to have implemented an internal Zope authentication/authorization database. Additionally, at: http://www.zope.org/Download/Unsupported there's an etcUserFolder (auth against /etc/passwd type files) and a UserDB (auth against an RDBMS) and sometime soon there might be an LDAPUserFolder based on something that smells a lot like an LDAP Database Adapter. > from one-way-encryption to Kerberos to LDAP, but not > necessarily just a > fixed algorithm. LDAP is an interesting possibility, but I don't like > the idea of being stapled to LDAP -- it's overkill for most > installations. I agree totally! My _real_ question was, in the internal User Folder component, whether to store passwords a) in their original form or b) as a hash or c) as a selectable option ... Of course, the c) is probably the best answer! --Rob

1 0

RE: [Zope] Security glitch on user-editing form
by Phillip J. Eby 11 May '99

11 May '99

At 03:59 PM 5/11/99 -0400, Rob Page wrote: > >As an example of our Open Source business model a current customer is >rather interested in LDAP and has asked us to develop some Zope >integration for it. LDAP stores the _hash_ of users' passwords (e.g., >crypt, MD5, SHA). Our LDAP effort will be very sensitive to this >approach. > >What are people's thoughts on storing password hashes instead of the >plaintext password? Of course, it would become impossible to offer the >"You Forgot Your Password For the Fifteenth Time" email messages... Actually, it's not impossible, so long as you change their password, generate a new one, and send it in the message... :) Seriously, storing hashes is much more secure than plaintext, IMHO. If you have a hash, all you get is the ability to test for possible passwords much faster. Granted, this does nothing about the transmission of the plaintext password to Zope in the first place... Where LDAP is concerned, I suggest a multi-leveled approach. First, encrypt the password stored on the LDAP server. Second, grant absolutely no-one the rights to *read* the password value, and only grant *compare* rights to the application server's login, perhaps restricting the IP/domain as well. Rather than using the LDAP bind operation to check the password, bind as an application server login and keep the connection open. Use the compare operation on the encrypted password attribute, so that you are not retransmitting the user's password in the clear. Now a hacker has to do a fair amount just to get to the point where they can start even *guessing* passwords... and they still have to try one password at a time against a single user, unless they can break into the LDAP server's underlying DB.

1 0

RE: [Zope] Security glitch on user-editing form
by Alexander Staubo 11 May '99

11 May '99

Any one-way encryption method will work, but why not modularized authentication support? Something that would permit you to use anything from one-way-encryption to Kerberos to LDAP, but not necessarily just a fixed algorithm. LDAP is an interesting possibility, but I don't like the idea of being stapled to LDAP -- it's overkill for most installations. Alexander Staubo http://www.mop.no/~alex/ mailto:redhand@mop.no >-----Original Message----- >From: Rob Page [mailto:rob.page@digicool.com] >Sent: 11. mai 1999 22:10 >To: 'Alexander Staubo' >Cc: 'zope(a)zope.org' >Subject: RE: [Zope] Security glitch on user-editing form > > >> I just found that Zope presents the user-editing form (manage_users) >> with the password in plaintext. That's a bit crude. >> > >As an example of our Open Source business model a current customer is >rather interested in LDAP and has asked us to develop some Zope >integration for it. LDAP stores the _hash_ of users' passwords (e.g., >crypt, MD5, SHA). Our LDAP effort will be very sensitive to this >approach. > >What are people's thoughts on storing password hashes instead of the >plaintext password? Of course, it would become impossible to offer the >"You Forgot Your Password For the Fifteenth Time" email messages... > >Idea? Comments? > >--Rob >

1 0

Z Classes Question
by Jeff K.Hoffman 11 May '99

11 May '99

Hello Zopesters, I am working on a project using 1.11pre and Z Classes, and have run into an interesting situation. First, let me tell you what I am trying to do. I need to create a structure like this: + class - index_html - document_a - document_b + instance - document_a Which is navigated to via http://mysite/instance. Why? Because the 'instance' folder might be seven levels deep, and I never want the user to know about its parents. Its context is always going to be the same (/class1/class2/classN/instance). So, I thought, why not use a Z Class? I made a 'class' Z Class which inherits from 'Object Manager' and defines 'index_html', 'document_a', and 'document_b'. So far so good. Now, what I want to be able to do is to create an instance of my Z Class, 'instance' and place a DTML Method inside it called 'document_a' which overrides the 'document_a' member of the Z Class. In this way, I could navigate to my site via http://mysite/instance/document_a and I would get the new, overloaded 'document_a', while navigating to http://mysite/instance/document_b would give me the 'document_b' inherited from the Z Class. This way, if I want a new instance of 'class', I can just drop it in place and be done with it. If, however, my new instance requires 'document_b' be slightly different than it was defined in 'class', I want to be able to easily customize it via the Zope Management interface. Now, however, when I try to drop a 'document_a' DTML Method in 'instance', I get a "Bad Request" error. I'm thinking Zope is not allowing me to create 'document_a' because 'document_a' is already there as part of the class. Is what I'm trying to do possible? If I didn't explain clearly enough, let me know and I'll try to clarify. :) Thanks, --jkh ____________________________________________________________________ Get free e-mail and a permanent address at http://www.netaddress.com/?N=1

2 1

RE: [Zope] Security glitch on user-editing form
by Rob Page 11 May '99

11 May '99

> I just found that Zope presents the user-editing form (manage_users) > with the password in plaintext. That's a bit crude. > As an example of our Open Source business model a current customer is rather interested in LDAP and has asked us to develop some Zope integration for it. LDAP stores the _hash_ of users' passwords (e.g., crypt, MD5, SHA). Our LDAP effort will be very sensitive to this approach. What are people's thoughts on storing password hashes instead of the plaintext password? Of course, it would become impossible to offer the "You Forgot Your Password For the Fifteenth Time" email messages... Idea? Comments? --Rob

1 0

RE: [Zope] Midgard
by Alexander Staubo 11 May '99

11 May '99

Christopher Petrilli wrote: >A'hoy! I knew Michel was up to something, my ears hurt... >Seriously though, >I think that there are some elegant ways to solve this. If >only there were >"cascading menus" in HTML ;-) [snip] But there are -- check out the optgroup tag (http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.6) This tag has, afaik, been since at least the HTML 3 draft, although it is not rendered ideally by browsers such as IE. (IE renders everything as a flat list -- too bad.) For example: <select name="ObjectToInsert"> <optgroup label="Zope"> <option label="Folder" value="...">Folder</option> <option label="File" value="...">File</option> </optgroup> </select> To enforce strict structures in the object list, I suggest using dot paths: eg., "Zope.Builtin.Folder", "Vendor.DigitalCreations.SQLMethod", etc. This permits sorting, and makes it possible to organize items into a hierarchical tree structure. Maybe the Products folder could be organized this way, too, rather than the flat structure we have today: Products/Zope/Builtin/, Vendor/DigitalCreations/, etc. -- Zope could glean the dot path from the physical installation path, simple as that. This scheme obviates duplicate identifiers, too: If I write a product called MyProduct, its identifier will be made unambiguious by the fact that it's installed into Products/AlexanderStaubo/MyProduct -- avoiding possible conflict with another MyProduct. Alexander Staubo http://www.mop.no/~alex/ mailto:redhand@mop.no

1 0

ZServer error messages
by Joachim Schmitz 11 May '99

11 May '99

Hello, I installed Zope-1.11 with ZServer on a SuSE 6.1 Linux and started ZServer successfully, here the output: joachim@js:/usr/local/Zope-1.11/ZServer > log: adding channel <trigger at 81a0938> log: adding channel <zhttp_server at 84188e8> Warning: computing default hostname Medusa (V1.6) started at Sun May 9 20:32:04 1999 Hostname: js.ac-copy.net Port:9673 log: adding channel <FTPServer at 8417c40> FTP server started at Sun May 9 20:32:04 1999 Authorizer:None Hostname: localhost Port: 9221 also when I invoke localhost:9673 everything looks fine in the browser, but on the console, where I startet ZServer I get a lot of those messages: uncaptured python exception, closing channel <caching_resolver connected at 8418818> (socket.error:(111, 'Connection refused') [medusa/asyncore.py|poll|56] [medusa/asyncore.py|handle_read_event|279] [medusa/resolver.py|handle_read|239]) uncaptured python exception, closing channel <zhttp_channel connected 127.0.0.1:1215 at 8431658 channel#: 2 requests:1> (socket.error:(9, 'Bad file descriptor') [medusa/asyncore.py|poll|61] [medusa/asyncore.py|handle_write_event|288] [medusa/asynchat.py|handle_write|143] [medusa/asynchat.py|initiate_send|199] [medusa/asynchat.py|refill_buffer|186] [Producers.py|more|108] [medusa/http_server.py|log|263] [medusa/logger.py|log|233] [medusa/resolver.py|resolve_ptr|324] [medusa/resolver.py|resolve_ptr|233]) ------------------------------------------------------------------------------ P R O F I . N E T A G * Joachim Schmitz * Senior Network Consultant ------------------------------------------------------------------------------ profi.net | Aindlinger Str. 7 | Voice +49 821 27062-0 Hassler & Mair AG | 86167 Augsburg | Fax +49 821 27062-99 | Germany | Email js(a)profi.net

2 2

RE: [Zope] Midgard
by Michel Pelletier 11 May '99

11 May '99

> -----Original Message----- > From: Martijn Pieters [mailto:mj@antraciet.nl] > Sent: Tuesday, May 11, 1999 10:26 AM > To: phd(a)sun.med.ru; Zope Mailing List > Subject: Re: [Zope] Midgard > > > At 14:20 11/05/99 , Oleg Broytmann wrote: > >Hello! > > > > Anyone saw the announcement of Midgard free Web > Applications platform? > >URL is http://midgard.greywolves.org/ > > They mention DTML as a method to extend their Syle system. > > Midgard seems primarily a template system, not an application > platform. > Really schnazzy graphics though! It *must* be better than Zope cuz it's logo is ANIMATED! Maybe we should steal their graphics guy and he can design a three dimensional Zope logo that spins on various axies on EVERY SINGLE PAGE of the managment interface. That would be really cool. -Michel (the Ruthless One)

2 1