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

[J C Lawrence]

On Tue, 18 Jan 2000 06:12:07 -0500 
Paul Everitt <paul@digicool.com> wrote:

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

While I see your argument, I'd argue in this particular case its
specious.  Using a token system as I specced but with long lived
cookies compromises no usability features and does add a (very
minor) level of greater security.

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

> Tell me how this is different from HTTP Basic Authentication.  

Not much.  That hardly makes it or HTTP Basic Authentication
acceptable however.

> The goal of PTK has, to date, _not_ been about improving the Zope
> security model.  However, increasing the usability has been a
> goal.

An excellent point.  

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

Minor quibble: its not a function of their physical security, but of
the physical security of their system, and every 'net node and wire
between them and the target site inclusive. Its the latter point
which is the killer, and one over which they have no control or
audit capability..

> You obviously feel strongly about this.  

I've just been burnt too often.  Within 48hrs of the first realm
based web system I'd setup, someone snooped a packetstream at an
intervening ISP (they'd temporarily replaced a switch with a hub
while they awaited a parts backorder) and mashed the site.

> After we make the code available, test your ideas and send some
> patches.  

I noticed a pre-package up on the products list.  Worth hacking on?

> Chris Petrilli, our security czar here, has had ideas about how to
> make a cookie algorithm significantly more secure than HTTP Basic.

Is he active in regard to PTK?  

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

Umm, really?  Cacheing is typically for server content, not client
content, and in particular this is bound to the HTTP request and not
the data stream.  As the above is sensitive only to client IP and
not server IP, this wouldn't seem a concern.

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

Perhaps I should rephrase the above:

  There is always the trade-off between usabilitya nd security.
That's nothing new.  I would argue however that we have a
responsibility for making a system that can be easily bolted down as
much as possible without involving crypto, even if it is also
possible to leave it wide-open/maximally usable.

My point is choice: the fact that PTK explicitly supports a
reasonably secure setup without, as you say, mandating it.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--