Mailing List Archive

> Amos, why do the cookies at Zope.org not contain all the login
> information, set to expire long into the future? This is the way most
> sites work. If you choose to set a cookie, you'll never need
> to log in
> again.

I think that the main concern is that anyone who used your browser would
then have access to your Zope.org account. Realistically this is not a
big deal for most classes of users.

I'm not sure if there are any other security issues involved in this
cookie arrangement.

> I imagine that we should provide some knobs to let portal
> owners choose
> different policies, but I think the default should be like
> other sites.

This sounds reasonable. I'm not sure if other sites in general work the
way you assert, but none the less it sounds like a friendlier solution
for the user.

However, I can imagine a case where the user's cookie gets lost for one
reason or another (for example, they change browsers) and if they are
not used to logging in, they will most likely not remember their
password. At this point they'll need to mail themselves their password.
Not a big deal I guess.

-Amos

Amos Latteier wrote:

... <snipped>
>
> > I imagine that we should provide some knobs to let portal
> > owners choose
> > different policies, but I think the default should be like
> > other sites.
>
> This sounds reasonable. I'm not sure if other sites in general work the
> way you assert, but none the less it sounds like a friendlier solution
> for the user.

Now I think I have wandered aimlessly enough on the web to comment on that one
;-)
Yes, most sites do give you a cookie so that you don't have to login again but
they allow you to disable that feature. They have a checkbox on the first
login page which says "Remember my Password" so that you know what you are
doing. There's also a "what's this" link next to the checkbox to explain
things.

> However, I can imagine a case where the user's cookie gets lost for one
> reason or another (for example, they change browsers) and if they are
> not used to logging in, they will most likely not remember their
> password. At this point they'll need to mail themselves their password.
> Not a big deal I guess.

Does this mean that the passwords are stored as plaintext in Zope? Many users
(including me) don't like the servers to store the passwords in plaintext. I
fear is that if the security of the passwords file is compromised, my password
is out - and I don't like that. Also because I know that hackers know that
people typically use the same password for a number of sites. I don't even
want the admin to know my password (sure, even if its encrypted he can change
my password, but he wouldn't know what password I used).
The way the lost password problem is solved with encrypted passwords is that
the server changes the user's password to a randomly generated string which it
also emails to the user.

~Shalabh
---------------------------------------------------------------
"We are all in the gutter,
but some of us are looking at the stars"
-Oscar Wilde
---------------------------------------------------------------

On Mon, 17 Jan 2000 11:19:23 -0500
Amos Latteier <Amos@digicool.com> wrote:

> I'm not sure if there are any other security issues involved in
> this cookie arrangement.

Its the same reason you don't use telnet on unprotected or untrusted
networks (and probably shouldne't even then). The general problem
is that anyone can sniff the wire, pick up the cookie, slap it in
their own cookie file and instantly impersonate you with all your
access rights. This is of course why people use things like SSL and
variously short lived session keys and the like.

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

> Its the same reason you don't use telnet on unprotected or untrusted
> networks (and probably shouldne't even then). The general problem
> is that anyone can sniff the wire, pick up the cookie, slap it in
> their own cookie file and instantly impersonate you with all your
> access rights. This is of course why people use things like SSL and
> variously short lived session keys and the like.

I just spoke with Chris Petrilli who agrees with you. The PTK should not
set long lived cookies with authentication information.

-Amos

Amos Latteier wrote:
> I just spoke with Chris Petrilli who agrees with you. The PTK should not
> set long lived cookies with authentication information.

I disagree. The "password in cleartext on the wire" is the same for
HTTP Basic Authenication as it is for cookies. If people want to
discard their login information, all they have to do is click "Logout".

The vast, vast majority of sites with identities, IMO, use long-lived
cookies, but ask people if it is OK. People building sites with our
software should be able to build sites as "usable" as competitive sites,
and have an option to clamp down as they wish.

--Paul

> I disagree. The "password in cleartext on the wire" is the same for
> HTTP Basic Authenication as it is for cookies. If people want to
> discard their login information, all they have to do is click "Logout".
>
> The vast, vast majority of sites with identities, IMO, use long-lived
> cookies, but ask people if it is OK. People building sites with our
> software should be able to build sites as "usable" as competitive sites,
> and have an option to clamp down as they wish.

I just signed up and am catching this thread in the middle, so
perhaps this has already been covered.

Sites like Amazon use a two-tiered approach. Whenever I return it
remembers who I am. No need to enter a password. And it returns
preferences and recommendations based on that identity. But if I
want to place an order, view my order history, or do other things
like that I need to sign on. The login form automatically inserts my
username (my email address in the case of Amazon) and I need to
supply my password. More personal information requires
authentication on a per session basis.

Yahoo! uses a similar two-tier approach. A Yahoo ID is valid for all
Yahoo services. The ID is long lived for my.yahoo.com. I never need
to enter my id/password unless I deliberately logged out. But the
Yahoo clubs is short lived, about 48 hours I think. Every 48 hours,
even if I never close Netscape during that time, I need to login
again. Both of these use the same username/password.

karl



-----------------------------------------------------------------
Karl Fast

----- Original Message -----
From: "Karl Fast" <karl.fast@pobox.com>
To: <zope-ptk@zope.org>
Sent: Monday, January 17, 2000 4:37 PM
Subject: Re: [Zope-PTK] DISCUSS: Why Zope.org has soft cookies


> > I disagree. The "password in cleartext on the wire" is the same for
> > HTTP Basic Authenication as it is for cookies. If people want to
> > discard their login information, all they have to do is click "Logout".
> >
> > The vast, vast majority of sites with identities, IMO, use long-lived
> > cookies, but ask people if it is OK. People building sites with our
> > software should be able to build sites as "usable" as competitive sites,
> > and have an option to clamp down as they wish.
>
> Sites like Amazon use a two-tiered approach. Whenever I return it
> remembers who I am. No need to enter a password. And it returns
> preferences and recommendations based on that identity. But if I
> want to place an order, view my order history, or do other things
> like that I need to sign on. The login form automatically inserts my
> username (my email address in the case of Amazon) and I need to
> supply my password. More personal information requires
> authentication on a per session basis.

So, maybe what is needed here is a three way switch:

1) Password must be entered for any user activity

2) User prefs can be read without password, but other action requires login

3) User never needs to enter the password

For case two, it would still be useful to have AUTHENTICATED_USER set up (so
that you can get the username, and prefs when prefs exist). Perhaps there
would be a flag to state whether the user has authenticated in this session,
or some such. As an alternative, there could be a different user object for
handling prefs that can be populated with a password, that way
AUTHENTICATED_USER is something that is only properly set when the user has
entered the password.

I could definitely see us going for the two-tiered approach that Karl talks
about.

Kevin

> > Sites like Amazon use a two-tiered approach. Whenever I return it
> > remembers who I am. No need to enter a password. And it returns
> > preferences and recommendations based on that identity. But if I
> > want to place an order, view my order history, or do other things
> > like that I need to sign on. The login form automatically inserts my
> > username (my email address in the case of Amazon) and I need to
> > supply my password. More personal information requires
> > authentication on a per session basis.
>
> I could definitely see us going for the two-tiered approach that Karl talks
> about.

What I like about the two-tiered (or multi-tiered) approach is that
it allows you to strike a balance between security and usability.
I'd hate to have to login every time I went to my.yahoo.com just to
see my personalize home page, but I'd be really nervous about not
having to logon to change personal information like my password.



-----------------------------------------------------------------
Karl Fast

On Mon, 17 Jan 2000 16:01:56 -0500
Amos Latteier <Amos@digicool.com> wrote:

>> Its the same reason you don't use telnet on unprotected or
>> untrusted networks (and probably shouldne't even then). The
>> general problem is that anyone can sniff the wire, pick up the
>> cookie, slap it in their own cookie file and instantly
>> impersonate you with all your access rights. This is of course
>> why people use things like SSL and variously short lived session
>> keys and the like.

> I just spoke with Chris Petrilli who agrees with you. The PTK
> should not set long lived cookies with authentication information.

More significantly never put a clear text password in a cookie. Put
in a time-sensitive session key or some such which maps to an
authentication. You then need to make sure that hacking up a cookie
of the appropriate pattern won't authenticate you -- the easiest way
of doing this is by keeping server-side state information logging
what session keys are currently out there and valid.

This is about as close as you can get to the old standard of "what
you have and what you know" with cookies.

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

On Mon, 17 Jan 2000 16:09:13 -0500
Paul Everitt <paul@digicool.com> wrote:

> Amos Latteier wrote:
>> I just spoke with Chris Petrilli who agrees with you. The PTK
>> should not set long lived cookies with authentication
>> information.

> I disagree. The "password in cleartext on the wire" is the same
> for HTTP Basic Authenication as it is for cookies. If people want
> to discard their login information, all they have to do is click
> "Logout".

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
your cookies. If you do anybody who sniffs a cookie gets everything
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.

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.

> The vast, vast majority of sites with identities, IMO, use
> long-lived cookies, but ask people if it is OK. People building
> sites with our software should be able to build sites as "usable"
> as competitive sites, and have an option to clamp down as they
> wish.

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.

Heck, even the above system used with long lived cookies is better
than nothing.

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

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

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