Michael, you inspired me to reimplement cookies this way. For my site, the
cookie table is the most frequently updated one (even though I do not grant
cookies to search engines). I will try to use this kind of implementation.
Even now, my users like the fact that they can stay signed on forever, but
now I can do it at no cost to myself.
A quick question, is there an existing perl module to do this sort of thing?
Igor
On Wed, Sep 16, 2009 at 12:11 PM, Michael Peters <mpet...@plusthree.com>wrote:
> On 09/16/2009 12:13 PM, Brad Van Sickle wrote:
>
> 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.
>>
>
> If you need to store per-session data about a client that the client
> shouldn't be able to see, then you just encrypt that data, base-64 encode it
> and then put it into a cookie.
>
> If you don't care if the user sees that information you just want to make
> sure that they don't change it then add an extra secure hash of that
> information to the cookie itself and then verify it when you receive it.
>
> I like to use JSON for my cookie data because it's simple and fast, but any
> serializer should work. Something like this:
>
> use JSON qw(to_json from_json);
> use Digest::MD5 qw(md5_hex);
> use MIME::Base64::URLSafe qw(urlsafe_b64encode urlsafe_b64decode);
>
> # to generate the cookie
> my %data = ( foo => 1, bar => 2, baz => 'frob' );
> $data{secure} = generate_data_hash(\%data);
> my $cookie = urlsafe_b64encode(to_json(\%data));
> print "Cookie: $cookie\n";
>
> # to process/validate the cookie
> my $new_data = from_json(urlsafe_b64decode($cookie));
> my $new_hash = delete $new_data->{secure};
> if( $new_hash eq generate_data_hash($new_data) ) {
> print "Cookie is ok!\n";
> } else {
> print "Cookie has been tampered with! Ignore.\n";
> }
>
> # very simple hash generation function
> sub generate_data_hash {
> my $data = shift;
> my $secret = 'some configured secret';
> return md5_hex($secret . join('|', map { "$_ - $data->{$_}" } keys
> %$data));
> }
>
> Doing encryption and encoding on small bits of data (like cookies) in
> memory will almost always be faster than having to hit the database
> (especially if it's on another machine). But the biggest reason is that it
> takes the load off the DB and puts it on the web machines which are much
> easier to scale linearly.
>
> > I know a lot of true app servers (Websphere, etc..) store
>
>> this data in cached memory,
>>
>
> You could do the same with your session data, or even store it in a shared
> resource like a BDB file. But unless it's available to all of your web
> servers you're stuck with "sticky" sessions and that's a real killer for
> performance/scalability.
>
>
> --
> Michael Peters
> Plus Three, LP
>
