This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: <modperl@apache.org>
From: "John Michael" <johnm@acadiacom.net>
Subject: Cookie authentication
Date: Thu, 15 Nov 2001 14:02:04 -0600
This may seem off subject but, If you bare with me, I don't
think it is. I am interested in using the cookie based
system referred to in the programming the apache api book
but oftend wonder this.
Can you count on everyone to use cookies. It seems that
some surfers are afraid of cookes are that maybe some
browsers don't even handle them. I wrote a mod perl script
to do member traking in my members site to see what pages
were being viewed the most and used cookies also to make
sure that more than one person was not using a particular
username and find that some people either arn't using a
browser that uses cookies or do not have them turned on.
What are your thoughts on this because I thought of
implementing the token cookie system but did not because I
was afraid I would loose members that did not have or use
this feature.
Can you legimately require surfers to have cookies turned on
and do you know of many sites that do this successfully
without loosing members.
==
To: "'John Michael'" <johnm@acadiacom.net>
From: Charles Day <Charles.Day@frontstep.com>
Subject: RE: Cookie authentication
Date: Thu, 15 Nov 2001 15:09:02 -0500
We rolled out cookie authentication (Auth::Cookie) for our secured support
website around Jan 2001 and we never received one complaint (and our people
complain about everything:)
It seems you can't do anything online without having cookies turned on (
yahoo, bankone, huntington, ebay, etrade ) and I think internet users have
accepted this.
Although Microsoft is doing it's best to screw this up:
http://abcnews.go.com/sections/scitech/TechTV/TechTV_IEflaw011109.html
<http://abcnews.go.com/sections/scitech/TechTV/TechTV_IEflaw011109.html>
fix:
<http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security
/bulletin/MS01-055.asp>
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/
bulletin/MS01-055.asp
===
To: Charles Day <Charles.Day@frontstep.com>
From: Andrew Ho <andrew@tellme.com>
Subject: Re: Cookie authentication
Date: Thu, 15 Nov 2001 12:16:42 -0800 (PST)
Hello,
CD>It seems you can't do anything online without having cookies turned on
CD>(yahoo, bankone, huntington, ebay, etrade ) and I think internet users
CD>have accepted this.
Not those clever European governmental folks, though.
http://www.vnunet.com/News/107416
http://news.zdnet.co.uk/story/0,,t269-s2099128,00.html
http://news.bbc.co.uk/hi/english/sci/tech/newsid_1653000/1653907.stm
http://www.cnn.com/2001/TECH/internet/11/14/eu.spam.cookies.idg/
Methinks there is a need to write a transparent "store cookies on URL"
module. I seem to recall at least one major Apache module having an option
to use URL-based authentication instead of cookie-based... but I can't
seem to find that from a cursory perusal of CPAN.
===
To: "Andrew Ho" <andrew@tellme.com>, "Charles Day"
<Charles.Day@frontstep.com>
From: "Perrin Harkins" <perrin@elem.com>
Subject: Re: Cookie authentication
Date: Thu, 15 Nov 2001 15:19:43 -0500
> I seem to recall at least one major Apache module having an option
> to use URL-based authentication instead of cookie-based... but I can't
> seem to find that from a cursory perusal of CPAN.
Apache::ASP does this.
===
To: mod_perl List <modperl@apache.org>
From: Joe Breeden <jbreeden@ena.com>
Subject: RE: Cookie authentication
Date: Thu, 15 Nov 2001 14:58:13 -0600
Before I read an article about the European Union POV of cookies I hadn't
really thought of myself as someone who would violate basic human rights. I
guess this goes to show that one has to be ever vigilant in today's society.
The resolution banning cookies did not pass the EU Parliament, this time. A
ban on unsolicited SMS messages like those sent via a cell phone was
approved
(http://www.cnn.com/2001/TECH/internet/11/14/eu.spam.cookies.idg/index.html)
.
We use cookies to track session state here and have had no complaints. I
don't think it is wrong to require the use of cookies. Of course to make
everyone happy you could backup cookies with some sort of non-cookie based
state management, like a URL encoded sessionid or a hidden form field passed
in every page. Like everything, your mileage will vary with any
implementation you choose to use.
====
To: mod_perl List <modperl@apache.org>
From: peter@schoenster.com
Subject: Re: Cookie authentication
Date: Thu, 15 Nov 2001 20:24:52 -0200
On 15 Nov 2001, at 12:16, Andrew Ho wrote:
> CD>It seems you can't do anything online without having cookies turned on
> CD>(yahoo, bankone, huntington, ebay, etrade ) and I think internet users
> CD>have accepted this.
> Methinks there is a need to write a transparent "store cookies on URL"
> module. I seem to recall at least one major Apache module having an option
> to use URL-based authentication instead of cookie-based... but I can't
> seem to find that from a cursory perusal of CPAN.
http://perl.apache.org/guide/modules.html#Apache_Session_Maintain_sessi
I used Apache::Session and HTML::Template to embed the
session_id in the url in a recent job site.I planned this before I built
the site (all templates built according to the plan :). No problems
there. There were no static pages.
I find cookies are used when one has a site static/dynamic pages.
How do you keep a user if they click to a static page? I don't
know.
But one should always check if a user has cookies turned on. I
recall an internal site I did for FedEx a few years back and I used
cookies for it as it was before my mod_perl use. Well it turned out
that the vice-president had cookies turned off. He was not a
customer we wanted to ignore:)
===
To: mod_perl List <modperl@apache.org>
From: Joe Breeden <jbreeden@ena.com>
Subject: RE: Cookie authentication
Date: Thu, 15 Nov 2001 16:42:07 -0600
Here we insert a session id on all requests, with Apache::Session whether
the request is for a static or dynamic page and have a TransHandler to strip
the session id and insert it into %ENV which seems to work for us. With this
approach we don't necessarily need cookies, but verifying if a user is who
the session was originally assigned to without a cookie is really
impossible. At least to me with the limited amount of brain time I have put
into it. Using some algorithm consisting of the end-users IP and some random
number is OK until users behind the same NAT device try to steal each others
session. Using the cookie is a way to verify that a user is the owner of the
session id.
I hope this doesn't sound like the ramblings of a mad man, but in general I
think SESSION cookies are ok and you should feel ok using them.
I hope this helps a little.
===
To: "Joe Breeden" <jbreeden@ena.com>, "mod_perl List"
<modperl@apache.org>
From: "Perrin Harkins" <perrin@elem.com>
Subject: Re: Cookie authentication
Date: Thu, 15 Nov 2001 17:52:10 -0500
> Here we insert a session id on all requests, with
> Apache::Session whether the request is for a static or
> dynamic page and have a TransHandler to strip the session
> id and insert it into %ENV which seems to work for
> us. With this approach we don't necessarily need cookies,
> but verifying if a user is who the session was originally
> assigned to without a cookie is really impossible. At
> least to me with the limited amount of brain time I have
> put into it. Using some algorithm consisting of the
> end-users IP and some random number is OK until users
> behind the same NAT device try to steal each others
> session. Using the cookie is a way to verify that a user
> is the owner of the session id.
Cookies are very easy to fake and modify on the client side. If you want to
verify that a user is returning a session ID you sent him without modifying
it you should use a MAC, like the ticket access stuff in the Eagle book.
===
To: "John Michael" <johnm@acadiacom.net>,
<modperl@apache.org>
From: Bill Moseley <moseley@hank.org>
Subject: Re: Cookie authentication
Date: Thu, 15 Nov 2001 15:06:46 -0800
At 02:02 PM 11/15/01 -0600, John Michael wrote:
>>>>
<excerpt>This may seem off subject but, If you bare with me, I don't
think it is. I am interested in using the cookie based system referred
to in the programming the apache api book but oftend wonder this.
Can you count on everyone to use cookies.
</excerpt><<<<<<<<
Sometime back I wrote a module based on Apache::AuthCookie called
Apache::AuthCookieURL that uses cookies, or falls back to munged URLs if
cookies were not enabled. It's on CPAN.
I wrote it for a site where people come in from public libraries. The
requirement was that it had to do sessions even if cookies were disabled
(as it was common for the public libraries to have cookies disabled).
It's been a while since I looked at it. I had added a way to disable the
authen requirement for areas of the site (or everywhere), so it could be
used just for dealing with sessions.
Do be careful about session hijacking.
===
To: <modperl@apache.org>
From: "John Michael" <johnm@acadiacom.net>
Subject: Re: Cookie authentication
Date: Thu, 15 Nov 2001 17:20:12 -0600
Thanks.
I did not know that you could verify that someone has cookies turned on.
Can you point me to where i can find out how to do this? Is there a
variable that you can check?
===
To: modperl@apache.org
From: Joe Breeden <jbreeden@ena.com>
Subject: RE: Cookie authentication
Date: Fri, 16 Nov 2001 09:38:55 -0600
Thanks David. It hadn't dawned on me to do the cookie storing/retrieving
over SSL - sometimes I need to be hit over the head with a sledgehammer to
see the obvious. Without some sort of secure mechanism to transport the
cookie between the browser and app all the app can be assured of is that the
cookie is valid. The app cannot be 100% certain that the cookie being sent
is sent by the real owner of the cookie. Generally, I would say that most
applications could use any of the proposals floated on the list yesterday
and today and not worry about client sessions being hijacked. Of course, if
a session is hijacked - how much damage is done is a question the developer
needs to ask themselves. If the risks are acceptable then what is in the
Eagle book and has been discussed is OK. If the risks are not acceptable
then what David suggests is the way to go.
And thanks to everyone who posted.
===
To: modperl@apache.org
From: Rob Nagler <nagler@bivio.net>
Subject: RE: Cookie authentication
Date: Fri, 16 Nov 2001 15:22:02 -0700
> If you happen to type in a URL, they can revive your
> session from the cookie. Pretty nifty trick.
This would seem to be a security hole to me. URLs appear in the logs
of the server as well as any proxy servers along the way. If the URL
contains reusuable auth info, anybody accessing any of the logs could
gain access to customer accounts.
> to prevent proxy caches from caching personalized pages
> and serving them to the wrong end-user.
If you want to ensure privacy, use:
$r->header_out('Cache-Control' => 'private');
If you want to turn off caching altogether, use:
$r->header_out(Pragma => 'no-cache');
===
To: <modperl@apache.org>
From: David Young <dyoung@nettonettech.com>
Subject: Re: Cookie authentication
Date: Fri, 16 Nov 2001 17:32:35 -0500
> Rob Nagler <nagler@bivio.net> wrote:
>> If you happen to type in a URL, they can revive your
>> session from the cookie. Pretty nifty trick.
>
> This would seem to be a security hole to me. URLs appear in the logs
> of the server as well as any proxy servers along the way. If the URL
> contains reusuable auth info, anybody accessing any of the logs could
> gain access to customer accounts.
As I mentioned before, if you dissect what they do with cookies and when,
you'll find they maintain two levels of session tracking, one for
"non-sensitive" personalization uses and one for "sensitive" authentication
uses. The URL session ID is likely only the former, and not exposing
anything sensitive.
I haven't spent a lot time seeing what they do when I disable cookies, but I
do know that if I copy an URL (which contains my session ID) and send it to
a friend, when that friend clicks on it, Amazon redirects to a new URL with
a different session ID.
===
To: <modperl@apache.org>
From: "Kyle Oppenheim" <kyleo@tellme.com>
Subject: RE: Cookie authentication
Date: Fri, 16 Nov 2001 14:45:09 -0800
> > If you happen to type in a URL, they can revive your
> > session from the cookie. Pretty nifty trick.
>
> This would seem to be a security hole to me. URLs appear in the logs
> of the server as well as any proxy servers along the way. If the URL
> contains reusuable auth info, anybody accessing any of the logs could
> gain access to customer accounts.
I disagree. The server logs are somewhat irrelevant because they should
already be under access control, and they could contain anything including
HTTP headers and content from post requests. As for proxies, they see the
entire HTTP transaction anyway. If they aren't trusted, the data should be
encrypted end-to-end with SSL. If the session-id is in the URL, an end-user
cannot accidentally get a personalized page intended for somebody else. As
you mentioned, you could prevent an intermediate cache from caching the page
with a "Cache-Control: private", but you then need to trust that the cache
is HTTP/1.1 compliant.
If anybody is afraid of using Amazon now, I believe David mentioned in a
previous post that Amazon switches to SSL (and a new session id) whenever
you deal with data they feel should be kept private. :-)
===
To: tom_bille@email.com
From: Jim Smith <jgsmith@moya.tamu.edu>
Subject: Re: Cookie authentication
Date: Mon, 19 Nov 2001 10:33:11 -0600
On Fri, Nov 16, 2001 at 02:09:25AM +0100, Tom Bille wrote:
> The aim of the cookie example in the eagle book is a bit
> more than just authentication. Most of the answers here to
> use a session ID here are quite right for most purposes,
> but the code in the eagle book offers to store information
> on the client side with the security of a signature. Its
> NOT just authentication. This has some advantages for
> applications which are on more than one server, which have
> to use an expensive central DB lookup and/or are not
> connected at all, since the only thing to share is the
> secret.
[snip]
And for the academically inclined, Authen::Ticket (which I need to go back
and update) is based on the Eagle book's example but different :/ It uses
a PKI-like solution for ensuring authenticity of the cookies (at least
someone can't just make up a cookie out of thin air). If you're using
FreeBSD, I believe there's even a port for it (much to my surprise).
===
To: modperl@apache.org
From: Nick Tonkin <nick@rlnt.net>
Subject: [OT] [But fun] Cookies and Microsoft
Date: Mon, 19 Nov 2001 12:18:45 -0800 (PST)
Speaking of the risks of using cookies for auth* stuff:
http://dailynews.yahoo.com/h/cn/20011119/tc/microsoft_apologizes_in_security_flap_1.html
===