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

Seb Potter seb at getfrank.com
Thu Jan 22 06:07:39 EST 2004


>> That said, making it securer is not necessarily a bad idea. For 
>> example, instead of username + password sent, a ticket could be sent as 
>> a cookie, and the zope-server could keep track of which user each 
>> ticket belonged too. That way the username and password is send only 
>> once, when you send the login form.
>
> Okay, but when and how does this ticket become invalid? Otherwise 
> someone could just snoop the ticket and we're back where we started...

When you're not using a secured authentication mechanism, this is an 
impossible problem to solve. Any transmission in cleartext is going to be 
interceptable.

This is a universal problem of using cookies as a method of providing 
persistent authentication. Cookies are a non-ideal solution that really 
should only be used in conjunction with an SSL-secured connection if 
you're worried about transmission security.

The point being: if you're using cookies for authentication and you're 
transmitting in cleartext, then your connection is open to a 
packet-sniffing attack, regardless of how you obfuscate your 
authentication token.

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

As far as I can see, the main reason to use cookies is to provide a 
friendlier login experience that simply a username/password/domain box. 
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.

- seb

-- 
Seb Potter
Senior Developer
Getfrank Ltd.



More information about the Zope-CMF mailing list