It amounts to shared private key security.

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

The session looks like 

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

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

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

I apply md5_hex from the Digest::MD5 module

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

Which yields

68b07c585c18282ea418937266b031d7 

I then construct my cookie.

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

So the cookie string looks like

premium:0:time:1253289574:username:dog:group:canid:68b07c585c18282ea418937266b031d7



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

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

die 'BOGUS SESSION' unless ($signature eq md5_hex(join '|', (map { $_, 
$session->{$_} } 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. 

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:bvansick...@gmail.com] 
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 
> sessions altogether if you can. If you need any per-session 
> information then put it in a cookie. If you need this information to 
> be tamper-proof then you can create a hash of the cookie's data that 
> you store as part of the cookie. If you can reduce the # of times that 
> 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 
be used for truly secure sites because I don't quite understand how 
storing a hash in a plain text cookie would be secure. 

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

Reply via email to