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

[Seb Potter]

On Fri, 23 Jan 2004 14:19:12 +0100, Dario Lopez-Kästen 
<dario at ita.chalmers.se> wrote:

> 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.

Exactly. If you're using Apache in front of your server (if not, why not?) 
then redirect incoming requsts to HTTPS before they even hit Zope.

>>>> 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.

Remember that you don't have any control over how the client stores 
session authentication tokens in cookies. Compromise of a remote terminal 
is not something you can work around from the server end in a web app.

> 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 this might work theoretically, in practice the inability to 
guarantee a connection to the server within a strict timeout limit, 
coupled with the increase in bandwidth, means that this is unworkable. 
(BroadVision used to do this, and it was one of the most frequently raised 
bugs about that system.)

>>>> 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.
>

If you're setting yourself up as a certification authority, then you 
should know what you're doing. Misconfiguration of issued certs is not a 
technical issue, it's an education issue of the person setting up the 
server. This is a complex and important issue, not something that you 
should even consider doing unless you are certain you know how to do it.

Get client certs from a trusted issuing authority such as Thawte. Ensure 
that you verify and trust the client's public cert. This is an incredibly 
important part of security that most people ignore. A client certificate 
on its own is useless. Ensure that you take steps to verify and trust the 
certificate and the identity of the user.


> 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.

For most users, yes. The question was about people who are paranoid about 
security. I develop Plone solutions for clients who are a bit more 
cautious about content publication than somebody using Plone to update a 
blog or a product catalogue. (Mostly government organisations where 
unauthorised content publication leads to national public enquiries and 
media witch hunts.)

Security is not something you can write off as 'good enough'. You solution 
must be commensurate with the value and importance of your data. As Plone 
is adopted by larger enterprise, it will be used for more and more 
applications that require higher levels of security. At these levels, 
cookie-based authentication just doesn't cut it.

- Seb

-- 
Seb Potter
Senior Developer
Getfrank Ltd.