This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: modperl list <modperl@apache.org>
From: Viljo Marrandi <vilts@bbz.ee>
Subject: Ticket systems
Date: Mon, 14 Jan 2002 13:08:31 +0200
Hello,
I'm on a mission ta make a web-site that uses cookies for user log-in
and log-out. First I'd like to know which one you suggest - Ticket
system from Eagle book or Apache::AuthTicket. I know that
Apache::AuthTicket is based on Eagle book's version, but it seems little
more advanced.
And now second problem. Has anyone modified one of these modules so,
that when user first enters the site he will get a cookie immediately
(with random generated ID) and can walk around there. And if he logs in
then the cookie gets modified accordingly (saying that user is logged
in).
Here's the situation. I must make a site for insurance company. User can
browse the site and see which offers he can get, if he wants to make a
deal only then he must log in. But all the data that is calculated must
be stored in dbase waiting for user to log in, so system can then, err,
bind this temporary data with current user. But of course user can log
in anytime he wants - even between different calculation steps.
Any ideas are welcome.
===
To: Viljo Marrandi <vilts@bbz.ee>
From: "Philip M. Gollucci" <philip@p6m7g8.com>
Subject: Re: Ticket systems
Date: Mon, 14 Jan 2002 06:55:29 -0500 (EST)
I am using Apache1.3.22/mod_perl1.26 with mod_usertrack.c
from httpd.conf
#User Tracking
LoadModule usertrack_module libexec/mod_usertrack.so
AddModule mod_usertrack.c
CookieTracking on
SetEnvIf Request_URI (\.gif|\.jpeg|\.js|\.css)$ junk
CustomLog /usr/local/sites/dev/logs/clickstream "%{cookie}n|%H|%m|%f|%U%q|%{User-agent}i|%{%m/%d/%Y %H:%M:%S}t" env=!junk
Along with a cron job and MySQL to gather the Website Statistics
But on this site, I also have say a Admin Section or a WWW Posting Board
The user doesn't have to log into until they go to that section at which point
I use the following modules to authenticate them against MySQL and give them a
cookie only if they auth correctly (Careful, Apache::Cookie is broken as far as
I can tell with Apache::Session::MySQL hence the CGI)
use Apache;
use Apache::Request ();
use Apache::Constants qw(OK REDIRECT);
use Apache::Session::MySQL;
use CGI qw(:standard);
use DBI;
===
To: modperl list <modperl@apache.org>
From: "C.Hauser - IT assistance GmbH"
<c.hauser@itassistance.ch>
Subject: Re: Ticket systems
Date: Mon, 14 Jan 2002 12:59:09 +0100
Same and more questions ...
> And now second problem. Has anyone modified one of these modules so,
> that when user first enters the site he will get a cookie immediately
> (with random generated ID) and can walk around there. And if he logs in
> then the cookie gets modified accordingly (saying that user is logged
> in).
I've got the same problem, as I'm using Apache::Session for generic
cookie handling. Which is comfortable and on top I've got any session
values stored in mySQL table.
Then I wanted to build in my old style login,storing an loginflag to
the actual session.
When a secured page/file/component/location is requested and no
loginflag is around he will be promted with a login page. So far so
easy.
Then I started to think ...
a) Is the sessionkey of Apache::Session secure? Can it be tampered? Is
some IP init?
b) Could I use one of the existing Auth/Ticket modules working in the
cookie of Apache::Session ... the same questions.
===
To: "C.Hauser - IT assistance GmbH"
<c.hauser@itassistance.ch>,
From: "Perrin Harkins" <perrin@elem.com>
Subject: Re: Ticket systems
Date: Wed, 16 Jan 2002 00:12:44 -0500
> a) Is the sessionkey of Apache::Session secure? Can it be tampered? Is
> some IP init?
It is not secure. If someone can guess a valid ID, they can hijack
another user's session. The default session generation code (using MD5)
is semi-random, but is not secure or guaranteed unique. The other two
(using mod_unique_id or mod_usertrack) are unique, but still not secure.
(Note that "hard to guess" is good enough for any web application that
doesn't deal with money or sensitive personal data.)
Apache::Session is just a data-sharing mechanism. It doesn't tell you
how to communicate the session key to the client. You can do it
securely if you need to.
> b) Could I use one of the existing Auth/Ticket modules working in the
> cookie of Apache::Session ... the same questions.
The AuthTicket module kind of assumes that you want to force users to
log in, not just verify sessions. It's not obvious how it could be used
for this. I would suggest that you take the code for verifying cookies
from either the AuthTicket module or the example in the Eagle book, and
use that with some basic cookie wrangling as your cookie management
code. Then you can use Apache::Session without fear, since you will be
verifying that the cookie being sent by the browser was generated by
your program.
Unfortunately, I don't know of anything that does this for you right
now. There was some talk about making a SessionManager module at one
point, but I don't see it on CPAN. There's some good code for this in
the AuthTicket module, but it makes too many assumptions to be used for
general purpose session tracking. Maybe you could convince one of the
authors to help you out by separating the actual cookie and verification
code from the rest.
===
To: "Viljo Marrandi" <vilts@bbz.ee>, "modperl list"
<modperl@apache.org>
From: "Perrin Harkins" <perrin@elem.com>
Subject: Re: Ticket systems
Date: Wed, 16 Jan 2002 00:31:46 -0500
> I'm on a mission ta make a web-site that uses cookies for user log-in
> and log-out. First I'd like to know which one you suggest - Ticket
> system from Eagle book or Apache::AuthTicket. I know that
> Apache::AuthTicket is based on Eagle book's version, but it seems
little
> more advanced.
>
> And now second problem. Has anyone modified one of these modules so,
> that when user first enters the site he will get a cookie immediately
> (with random generated ID) and can walk around there. And if he logs
in
> then the cookie gets modified accordingly (saying that user is logged
> in).
I don't think there's an existing solution that exactly meets your
needs. You need a sort of mix of Apache::AuthTicket and
Apache::Session, i.e. a secure cookie manager for use with
Apache::Session. See my other comments on this thread for more
explanation.
===
To: modperl@apache.org
From: "Jeffrey W. Baker" <jwbaker@acm.org>
Subject: Re: Ticket systems
Date: 15 Jan 2002 21:37:13 -0800
On Tue, 2002-01-15 at 21:12, Perrin Harkins wrote:
> > a) Is the sessionkey of Apache::Session secure? Can it be tampered? Is
> > some IP init?
>
> It is not secure. If someone can guess a valid ID, they can hijack
> another user's session. The default session generation code (using MD5)
> is semi-random, but is not secure or guaranteed unique. The other two
> (using mod_unique_id or mod_usertrack) are unique, but still not secure.
On many operating systems, Apache::Sessions's session ID is generated by
hashing data from /dev/random, which is about as good as anything.
===
To: modperl@apache.org
From: "Jeffrey W. Baker" <jwbaker@acm.org>
Subject: Re: Ticket systems
Date: 15 Jan 2002 21:46:58 -0800
On Tue, 2002-01-15 at 21:31, Perrin Harkins wrote:
> > I'm on a mission ta make a web-site that uses cookies for user log-in
> > and log-out. First I'd like to know which one you suggest - Ticket
> > system from Eagle book or Apache::AuthTicket. I know that
> > Apache::AuthTicket is based on Eagle book's version, but it seems
> little
> > more advanced.
> >
> > And now second problem. Has anyone modified one of these modules so,
> > that when user first enters the site he will get a cookie immediately
> > (with random generated ID) and can walk around there. And if he logs
> in
> > then the cookie gets modified accordingly (saying that user is logged
> > in).
Sure, that's the way *all* my security management systems work.
Everybody has a session all of the time, and their login state is simply
determined by frobbing a bit in their session.
Also I strongly suggest that you should not store any information in the
cookie, other than a token that identifies the session. Storing actual
data in the cookie is difficult and error-prone.
===
To: "Jeffrey W. Baker" <jwbaker@acm.org>,
<modperl@apache.org>
From: "Perrin Harkins" <perrin@elem.com>
Subject: Re: Ticket systems
Date: Wed, 16 Jan 2002 01:02:39 -0500
> On Tue, 2002-01-15 at 21:12, Perrin Harkins wrote:
> > > a) Is the sessionkey of Apache::Session secure? Can it be
tampered? Is
> > > some IP init?
> >
> > It is not secure. If someone can guess a valid ID, they can hijack
> > another user's session. The default session generation code (using
MD5)
> > is semi-random, but is not secure or guaranteed unique. The other
two
> > (using mod_unique_id or mod_usertrack) are unique, but still not
secure.
>
> On many operating systems, Apache::Sessions's session ID is generated
by
> hashing data from /dev/random, which is about as good as anything.
Well, it's very hard to guess, but it's not guaranteed unique or secure
from attempts to guess it. I don't think security of this kind
(verifying that the cookie came from this server and has not been
tampered with) is Apache::Session's problem, and the mod_unique_id
integration provides uniqueness, so I don't see this as something that
needs fixing in Apache::Session. It's something that a person
implementing the cookie management part needs to worry about, if they
run a site that is deeply concerned about session data staying private.
===
To: "Perrin Harkins" <perrin@elem.com>, "Jeffrey W. Baker"
<jwbaker@acm.org>,
From: "Les Mikesell" <lesmikesell@attbi.com>
Subject: Re: Ticket systems
Date: Wed, 16 Jan 2002 08:10:16 -0600
>From: "Perrin Harkins" <perrin@elem.com>
> > On Tue, 2002-01-15 at 21:12, Perrin Harkins wrote:
> > > > a) Is the sessionkey of Apache::Session secure? Can it be
> tampered? Is
> > > > some IP init?
> > >
> > > It is not secure. If someone can guess a valid ID, they can hijack
> > > another user's session. The default session generation code (using
> MD5)
> > > is semi-random, but is not secure or guaranteed unique. The other
> two
> > > (using mod_unique_id or mod_usertrack) are unique, but still not
> secure.
> >
> > On many operating systems, Apache::Sessions's session ID is generated
> by
> > hashing data from /dev/random, which is about as good as anything.
>
> Well, it's very hard to guess, but it's not guaranteed unique or secure
> from attempts to guess it. I don't think security of this kind
> (verifying that the cookie came from this server and has not been
> tampered with) is Apache::Session's problem, and the mod_unique_id
> integration provides uniqueness, so I don't see this as something that
> needs fixing in Apache::Session. It's something that a person
> implementing the cookie management part needs to worry about, if they
> run a site that is deeply concerned about session data staying private.
Do any of the existing modules offer any cookie checking? I've always
thought that a module should add an MD5 hash of the values of a
specified set of cookies plus a secret key and validate them when returned.
The secret key should be replaced at time intervals with both the current
or previous code accepted by the input check. This scheme would work
across multiple machines as long as the secret key can be updated on all
of them within the time interval and they wouldn't need any other database
connectivity in common. The values themselves could be encoded or
plain text. Stealing a copy would only work for the timeout interval (x2)
and any modification would invalidate them.
Les Mikesell
lesmikesell@attbi.com
===
To: "Les Mikesell" <lesmikesell@attbi.com>,
<modperl@apache.org>
From: "Perrin Harkins" <perrin@elem.com>
Subject: Re: Ticket systems
Date: Wed, 16 Jan 2002 11:51:59 -0500
> Do any of the existing modules offer any cookie checking? I've always
> thought that a module should add an MD5 hash of the values of a
> specified set of cookies plus a secret key and validate them when
returned.
That's what the TicketAccess module in the Eagle book does, and there's also
an implementation in AuthCookieURL. What these guys were hoping to find is
some plug-and-play module that puts that together with Apache::Session or
similar to store user information. Unfortunately that doesn't exist on CPAN
right now, so that's why I said they will have to code the cookie handling
and verification parts themselves (although this is made fairly easy by the
free code in the Eagle book and AuthCookieURL).
===