On 12/04/2004, at 10:39 PM, Shane Hathaway wrote:
On Mon, 12 Apr 2004, Chris Withers wrote:
I think the attached patch (against CookieCrumbler 1.1) makes CookieCrumbler a little more secure.
Your patch won't work with multiple ZEO app servers. It appears to store
the tokens in a module global. Do not apply it.
I've attached some similar code we are using. Instead of patching CookieCrumbler, it extends it and is drop-in compatible. We are stuffing the auth credentials into the SESSION, so it will work with ZEO if your SESSION machinery copes (either using server affinity or your session storage is mounted by the ZEO clients from a central storage).
I was going to pack this up and release it as a product under BSD or MIT licence, but I either forgot or came up with a technical reason not to. Either way, I'm having memory issues :-)
Description: Binary data
Does this look worth releasing as a separate product?
PS: To make cookie auth properly secure, you really need to be working over SSL only
I agree--SSL is required. Let's not give people a false sense of security by changing CookieCrumbler.
Unfortunately it causes performance to blow. We compromise by having the auth form on the SSL server, but the rest of the application on raw HTTP. This at least reduces the window that a replay attack can be used. It would be possible to tie the auth credential down to a particular IP address, but that is entering the world of diminishing returns and incompatibilities (think ISP's with farms of proxies - is this still a problem nowadays?).
-- Stuart Bishop <[EMAIL PROTECTED]>
Description: This is a digitally signed message part_______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )