[Zope-CMF] Re: [Plone-developers] PLIP - Ship SessionCrumbler instead of CookieCrumbler

[Jean-Marc Orliaguet]

Simon Eisenmann wrote:

>On Tue, 2004-10-12 at 10:00 +0200, Jean-Marc Orliaguet wrote:
>  
>
>>Simon Eisenmann wrote:
>>
>>I have tried SessionCrumbler:
>>
>>Problem #1: performance drops
>>    
>>
>Why should sessioncrumbler be slower than cookiecrumbler? I havent seen
>any slowdown by switching to SessionCrumbler. If its really slower then
>there is a bug somewhere which surely can be resolved.
>  
>
Hi!

I have noticed a significant performance drop with CPS, it is not as 
significant with Plone or CMF though. This occurs before the page is 
rendered, probably a 0.2-0.3 second gap where nothing happens. I don't 
know why, I tried both with ZEO and without ZEO.

>>Problem #2: is it really more secure?
>>I suppose that it is going to be marketed as a "more secure 
>>CookieCrumbler" for Plone.
>>Fine, except that it is not. It opens a new series of possible attacks 
>>while giving the user a feeling of security. The only thing an attacker 
>>    
>>
>
>It really is more secure, but it is not secure. Acually anything is more
>secure than CookieCrumbler. CookieCrumbler stores the user password in
>plain text on the filesystem of the browser. This is worst case.
>Security with SessionCrumbler is completely done on the server side,
>which is usually a lot more secure than the client system.
>
>  
>
It is more secure in a sense, and less secure in another sense, it just 
moves the weakest link from one place to another..
If you are doing external authentication (krb, cas, AD, ...), then the 
only viable alternative is to not store the password anywhere, this is 
when it becomes more secure, otherwise any other option is just as 
insecure since the main password can get compromised.

>I am not proposing a secure login for plone.
>
>What security itches SessionCrumbler removes:
>
> - password no longer transmitted on every single request
>   in plain text
>
> - password no longer stored in plain text on the clients filesystem
>
>What security itches SessionCrumbler creates:
>
> - sessions can be overtaken by guessing the session id
>
> - server side scripts could read the password from the session
>
>  
>

Why not push for a *real* secure implementation then instead of patching 
a hack?
It is a bit like saying: the front door is no longer left open, but now 
you can get in through the window instead and climbing through the 
window is more difficult.
That gives the user a false sense of security.

>>to be adapted to not expose it in the URL.
>>    
>>
>
>The session which is used is the usualy zope session. The session id is
>transmitted inside a cookie anyway. So no applications need any
>modification for this.
>
>  
>
there is an option to make it appear in the URL, it will be transmitted 
in the HTTP_REFERER variable.
see http://www.medic.chalmers.se/~jmo/CPS/browser_id.png

>You have to know that the session date itself is not stored on the
>client side ( a cookie or something ). Its stored inside the servers
>memory and so a lot harder to reach.
>
>Again i am not talking about secure logins .. i am just talking about
>removing a major security issue.
>
>Best regards,
> Simon
>
>  
>
Best /JM