I was wondering if my solution to the problem outlined
below would be a useful inclusion into the main CMF
> code tree?
Well, CookieCrumbler *should* be on a downhill path anyway, with PluggableAuthService (PAS) coming strong now, so I would suggest that moving to PAS would be a better idea.
That said, CookieCrumbler currently is about the least secure authentication method that it is possible to devise. ;) The only unsecure thing it doesn't do is store it on disk, since the cookies are set to expire when you close the browser.
CookieCrumbler, as well as standard Basic HTTP Authentication, sends the username and password, unencrypted, with every request. This is obviously not a very good idea. This is open for a whole host of possible ways of figuring out your username and password.
The easiest way to solve that is to let the cookie be only a random ticked. That way the userame and password is only sent when actually logging in. This gives as much security as your solution, but it's easier to implement. PluggableUserFolder does, and I think PAS does it do (or at least it will do that soon). This means that it will be a bit harder to figure out your username and password. You'll need to intercept the login request. You still can intercept ANY request and then use this to hijack the authentication ticket and subsequently use your logged in account, so it is still not much security to talk about. It is an easy enough improvement to do, so it should be done, but it given no significant extra security.
Cookie hijacking is possible to prevent by only allowing one ticket to come from one IP-address. Unfortunately, doing that will also make it practically impossible to login from most dial-up (including ADSL) connections. I have suggested that an option for binding sessions to IP-adresses should be added to the session handler, so that it can be enabled for intranets for example. But for most sites it's not a practical solution. And you can still get the username and password by tapping into your login requests.
The next step up in security after that is the largest, most difficult, but also most effective step: Using SSL.
By slapping an Apache server in front of the webserver, or using one of the native Zope SSL products, you can get encrypted communications between the client and the server. You can then NOT find the username and password, and you can NOT hijack the cookies, buceuase you can't intercept and decrypt the submitted data. Problem solved.
So, in short: If you want some extra security: Use PAS. If you want real security, use SSL.
--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
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 )
