[Plone-users] Re: [Zope-CMF] CookieCrumbler security issue?

[Dario Lopez-Kästen]

Seb Potter wrote:
>> Yup, but see my question to Lennart, I'm particularly concerned about 
>> when you have an HTTPS and an HTTP site at the same domain...
> 
> 
> Don't. Really, seriously. Use HTTPS for all login/authentication, and do 
> it on a different domain. Make it *impossible* to log in from the HTTP 
> domain.

a way to do this could be to have a SiteAccess script that checks 
whether the request comes in thru https or not. If not over https, then 
invalidate the session imediately,delete cookies om client, and redirect 
to login -page over https.

>>> Of course, using cookies will always expose you to the worst security 
>>> nightmare: compromise of the remote terminal. (Fortunately, without 
>>> being able to control the end-user, there's not a great deal you can 
>>> do about this in a web environment.)

this could be taken care of of you time out the cookie on the server 
side in conjunction with sessions (as i think you allready disscussed). 
The timeout being of a reasonable lenght... we use 15 minutes, and store 
cookies only in the RAM of the browsers. This way we are reasonably sure 
that as long as the user closes all browsers windows, s/he is reasonably 
protected.

Theoretically: I susspose that with clever usage of frames and a refresh 
tag or with some javascript magic/xml-rpc, the time out could be as low 
as 10 seconds or so (assuming the time out of the ticket on the server 
is refreshed by the client), in effect keeping the session open as long 
as the page to the site is open. Close the page and the session expires 
after 10 seconds.

>>> Whilst I agree that this is a fair compromise in most cases, it 
>>> certainly is not the right route if you're paranoid about security.
>> What would be?
> 
> Don't allow any authentication over HTTP whatsoever. Do it all over 
> HTTPS with 128-bit server certs, and require client certificate in order 
> to connect. Enforce secure authentication tokens (20 character random 
> passwords on 30 day rotation).

While I agree that this is a desirable feature, though I am not really 
convinced of using client certificates unless either backed up by a 
really well setup CA (which hard and costly and buerocratic if you do it 
yourself) or if you "outsource" it to some other company like, say 
Thawte, that has such arrangements (we do this to some extent, but not 
for client certs). I am assuming that if you need this kind of security, 
then cost is not a major obstacle.

If you set up your own CA, the doing the cert issuing wrong might 
actually be hamfull in itself, even if it works for your web-server, 
since you are putting a great deal of trust in the certificates. If you 
don not protect the process of issuing certs, then you are potentially 
comprimosing your whole CA infrastructure.

MHO is that doing cookie based auth with "tickets" as cookie values, 
using 128-bit and ensuring that all logged in communications occur over 
SLL before accepting them, coupled with a timeout of the ticket on ter 
server side is appropiate for most uses.

YMMV.

Sincerly,

/dario

-- 
-- -------------------------------------------------------------------
Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech.