Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of dihnen@amazon.com designates
 207.171.184.25 as permitted sender)
From: "Ihnen, David" <dihnen@amazon.com>
To: mod_perl list <modperl@perl.apache.org>
Date: Fri, 18 Sep 2009 09:16:33 -0700
Subject: RE: Ways to scale a mod_perl site
Thread-Topic: Ways to scale a mod_perl site
Thread-Index: Aco4R7OSFSn0r9oER7Wc4FFAkKXN+gAMRoPw
Message-ID: 
 <A8A10D7B10169F49A69BB4DDEF597851018C282232@EX-SEA5-D.ant.amazon.com>
References: <e86b7d350909160849vb4a9c5dt3b8793d187521ddd@mail.gmail.com>
 <4AB10CB8.7010202@plusthree.com> <4AB10EA2.70108@gmail.com>
In-Reply-To: <4AB10EA2.70108@gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

It amounts to shared private key security.

Each web server, for instance, is configured with the key abcd1234

The session looks like=20

{ username =3D> 'dog'
, group =3D> 'canid'
, premium =3D> 0
, login_time =3D> 1253289574
}

I serialize that into a string with join '|', (map { $_, $session->{$_} } s=
ort keys %session;

$cookiebase =3D login_time|1253289574|group|canid|premium|0|username|dog

I apply md5_hex from the Digest::MD5 module

$signature =3D md5_hex($cookiebase . "|" . 'abcd1234');

Which yields

68b07c585c18282ea418937266b031d7=20

I then construct my cookie.

$cookie =3D join ':', %session, $signature;

So the cookie string looks like

premium:0:time:1253289574:username:dog:group:canid:68b07c585c18282ea4189372=
66b031d7


When I receive the cookie on a request I just do the inverse.

my (%cookie, $signature) =3D split /:/, $cookie;

die 'BOGUS SESSION' unless ($signature eq md5_hex(join '|', (map { $_, $ses=
sion->{$_} } sort keys %cookie), 'abcd1234';

If you change the 'plaintext' string in any way - the md5_hex will change. =
 If you change or drop the signature, the md5_hex will change.=20

Its security through obscurity admittedly - security in that you can't see =
my code, methodology, or shared secret configuration.

But most people consider that plenty secure for securing the session data.

David


-----Original Message-----
From: Brad Van Sickle [mailto:bvansickle3@gmail.com]=20
Sent: Wednesday, September 16, 2009 9:13 AM
To: Michael Peters
Cc: Mod_Perl
Subject: Re: Ways to scale a mod_perl site


>
>> 3) Being enabled by item 2, add more webservers and balancers
>> 4) Create a separate database for cookie data (Apache::Session objects)
>> ??? -- not sure if good idea --
>
> I've never seen the need to do that. In fact, I would suggest you drop=20
> sessions altogether if you can. If you need any per-session=20
> information then put it in a cookie. If you need this information to=20
> be tamper-proof then you can create a hash of the cookie's data that=20
> you store as part of the cookie. If you can reduce the # of times that=20
> each request needs to actually hit the database you'll have big wins.
>
>

Can I get you to explain this a little more?  I don't see how this could=20
be used for truly secure sites because I don't quite understand how=20
storing a hash in a plain text cookie would be secure.=20

The thing I hate most about my "secure" applications is the fact that I=20
have to read the DB at the start of every request to ensure that the=20
session cookie is valid and to extract information about the user from=20
the session table using the session ID stored in the cookie.  Hitting=20
the DB is the quickest way to kill performance and scalability in my=20
experience.    I know a lot of true app servers (Websphere, etc..) =20
store this data in cached memory, but I was unaware that there might be=20
an option for doing this without using a DB with mod_perl .