[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