[Zope] Re: Question about Zope and security

[Chris Withers]

Cyrille Bonnet wrote:
> 
> I am using Plone 2.1.2, which uses CookieCrumbler. I wanted to put the 
> problem in a Zope perspective, though: this is why I didn't mention that.

Then I'd suggest going and bugging the Plohn people about this.
CookeCrumbler _is_ insecure, and I've pointed this out and provided 
convoluted patches in the past. But even with those patches, you _still_ 
need to use https to get real security ;-)

> I had thought of SSL, but it doesn't solve the problem for WebDAV access.

Huh? WebDAV over SSL will work just fine...

> I should also mention that the site is for the general public, with a 
> few users logging in.

So have the users who need to log in use a different subdomain, and make 
sure that's all SSL encrypted.

> Of course, I can't put the public site on SSL, 

Why not? If you're _so_ fussed about security, that's what you _need_ to 
do...

> It seems so much simpler to solve the problem at the root: change Zope 
> authentication.

Great, patches accepted. But please bear in mind we will rip them to 
shreds, especially if they use cookies or don't use SSL...

> I'd rather encrypt passwords with a hash and reset the password if the 
> users have lost it. Is it possible to do that in Zope?

You can do anything you want, you just have to write the code.

> * why is Zope authentication implemented that way?

what way? http basic auth is a standard. cookie auth isn't, and it's 
always insecure no matter how you implement it

> * Is it really complex to secure the authentication process?

Yes. Always. Get over it. You _will_ screw it up so stop getting you 
knickers in a twist...

> * Is there any documentation summing up Zope security (authentication 
> process, password storage, etc.)?

Probably. Why don't you have a look? Failing that, there's always the 
source code...

Seriously, you're worrying about stuff you shouldn't.

If you really care about security, unplug your server put it in a safe 
and leave it there. And pay someone to guard it and make sure no-one 
even sets eyes on it, let alone powers it up.

If you're moderately concerned about security, https _all_ your website 
interactions. Use client-side certificates to authenticate over SSL. 
Rigorously train all your users about security.

cheers,

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
            - http://www.simplistix.co.uk