It's some time ago, the issue of denying roles showed up. I'd really wish to see this implemented, so has this problem made it into the collector? (The feature index seems broken to me at the moment) Thanks to John for pointing out what i thought :) Bernd On Thu, Mar 01, 2001 at 10:00:13AM +0000, Chris Withers wrote:

"John R. Daily" wrote:

...

That is precisely what is wrong with the model. To achieve manageable and genuine security, I want to acquire _all_ permissions and specifically deny those roles to which the inherited permissions may not be correct.

I'd agree with this, but I don't know how important it is.

I'd suggest chucking it in the colelctor asa Featuer Request.

cheers,

Chris

_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )

-- -----Bernd Worsch-----------bernd.worsch@frontsite.de--------

On Mon, Mar 19, 2001 at 12:07:05PM -0500, Bill Welch wrote:

To achieve genuine security, you have to do something about the 'password in the clear' problem.

part 1) With basic auth (the zope default), the user's name and password are sent in the clear with every request.

part 2) With form based login (login manager, zmc), the user's name and password are sent in the clear when the login form is submitted.

Solution: Have to go with form based login that uses ssl to send user's name and password. Unfortunately, in my experience, ssl support for zope is only thrid party (no offense to Mr. Siong or Mr. Bickers, thanks for your work so far) and hard to integrate, when this is really a core requirement.

I think this is something that DC has to handle.

Bill.

Well your quite right, but this is another problem with zope security and more or less independent of zope security management features. BTW isn't it normally recommended to shield z-server by apache doing for the ssl stuff? If so, then there at least is some workaround possible. The kind of complicated and unusal management of security in zope on the other hand applies even, when only doing intranet stuff without any connection to the outside. As pointed out before the problem isn't that one can't realize the security policy he/she wishes but that it is quite painful at times. Suppose the following object/folder hierarchy: A containing AA and AB. AA containing AAA and AAB, AB containing ABA and ABB. A AA AAA AAB AB ABA ABB Suppose there is a role R which grants access to some objects. All the users have role R everywhere except in AAA and ABA. As far as i know there is no way to realize this security policy using role R alone. What you can do, is click through the security tabs in AAA and ABA so that role R isn't known in AAA and ABA blocking access to them. Then you define the role S in AAA and ABA, by checking the same boxes as you had in role R. Now you can give some of your users the local role S in AAA and ABA. So, it works but it isn't really funny. But maybe i'm mistaken and there is an elegant solution for this kind of policy? best regards Bernd -- -----Bernd Worsch-----------bernd.worsch@frontsite.de--------

On Mon, 19 Mar 2001 19:37:11 -0000 Phil Harris <phil.harris@zope.co.uk> wrote:

Bill,

There is another answer to part 2, use javascript to create an md5 hash of the user,somesecret,password.

This can be sent instead of the password and then validated on the server side, since the username and md5 hash is all that is sent across the wire, it should be a lot more secure than plain text.

I have a library for javascript md5 if anyone is interested (which,btw, I 'stole' from the PHPlib ;) ).

This method, as described, will not protect you from traffic sniffing at all. Where the attacker was sniffing for username and password combinations being submitted to the login page, they now sniff for an MD5 sum that will do the same job. Once in, the attack probably won't have too many problems changing the password to something they know. What it comes down to, is that any regular form based (initial) authentication scheme will involve sending authenication data using a known, and necessarily publicly accessable formulation (the login form) to a known and public URL that will decide whether to authenticate the user or not. As a result, an attacker can trivially find out what an authenication token should look like, and extract them at their leisure. You could probably transform the simple passive sniffing attack to a more complex man-in-the-middle attack by including a unique id for each login form hit and only accepting authentication tokens with a given id once. An attacker would need to intercept the authentication token and use it instead of the user in order to gain access. Coupled with short timeouts on the live ids, and a policy that users can only be logged in once, and you'll have tighter security than a plaintext password system - but it's still nowhere near as good as using SSL so that authentication tokens cannot be distinguished from any other traffic in the stream. John

Thanks for all the responses to the 'password in the clear' segment of this thread. I see another issue arising out of this. For all the effort that's gone into authentication/authorization/rols, nothing has been done about enforcing encryption. By that, I mean distinguishing requests that can only be sent over encrypted channels. SSLAbsoluteURL, AFAIK, can't prevent someone from constructing a url to get the same page in the clear. Short of going to an all SSL site, I haven't found any useful way to ensure that confidential pages are available *only* encrypted.

Given the availability of Apache+SSL (and otherz like Roxen) to front-end Zope, we are highly unlikely to add SSL into the Zope core; it incurs non-trivial development and configuration costs for those who *don't* need it.

OK, the issue isn't the encryption method (SSL), it's designating pages as confidential and ensuring that their delivery is encrypted. I think it has to be designed into zope just as solidly as users and roles. That's why I think there's a DC issue here. Bill.