[Zope-PTK] DISCUSS: Why Zope.org has soft cookies

[Paul Everitt]

J C Lawrence wrote:
> This is partially a human factors question and partially a 
> security model question.
>
> The thing you don't want to do is to put your PWs in the clear in

Please rephrase this to say, "The thing _I_ don't want to do..."  My
argument is, let the administrator make the human factors vs. security
tradeoff.

> your cookies.  If you do anybody who sniffs a cookie gets everything

Tell me how this is different from HTTP Basic Authentication.  The goal
of PTK has, to date, _not_ been about improving the Zope security
model.  However, increasing the usability has been a goal.

> forever (they can go change the PW and lock the person out etc).
> What you do instead is set up some sort of short lived
> authentication token that matches a record on the server and equates
> to "logged in".  If someone sniffs the cookie they can then only get
> in for the short period that the cookie lives. You then require PW
> authentication in addition to the token for all major operations
> such as PW changes, account creations, etc.

That's fine, I'd love that, I agree that's more secure, no argument
here...except, increasing Zope's secuirty hasn't been a mandate of PTK. 
Long-lived cookies that are optional, both at the client and server, are
only less secure than HTTP Basic authentication in the case that
someone's physical security is compromised.

You obviously feel strongly about this.  After we make the code
available, test your ideas and send some patches.  Chris Petrilli, our
security czar here, has had ideas about how to make a cookie algorithm
significantly more secure than HTTP Basic.

> In fact you can extend this a *little* further by requiring all
> instances of the same token to be presented from the same IP that
> originally created the token.  This is not really secure as it
> doesn't protect against IP spoofing and a host of other silliness,
> but it is about as close as you can get to a decently tight system
> without involving digital signatures and cryto.  It is about as
> close as you can get to the old basic of "what you have plus what
> you know" with cookies.

Tying to IP also breaks intermediate caching strategies.

> There is always the trade-off between usabilitya nd security.
> That's nothing new.  I would argue however that e have a
> responsibility for making a system that can be easily bolted down as
> much as possible without involving crypto.

Precisely my point.  The tradeoff is a choice that _they_ make, not one
that we mandate.

--Paul