Home/ Questions/Q 124453
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T05:00:09+00:00

I’m considering ditching PHP’s $_SESSION (i.e. the server-side session handling, to add some language-agnostic

  • 0

I’m considering ditching PHP’s $_SESSION (i.e. the server-side session handling, to add some language-agnostic flavor) and using signed cookies instead, since I’ve heard so much good about them (Flickr uses them, so they ought to be good enough for me too).

I understand the basic context of the technique: Use cookies freely to pass key-value pairs from client to server, and sign them to make sure that the values aren’t tampered with.

But what would be a good way to implement the signing part? Also; since the traffic will probably be HTTP, is there a good way to send sensitive data (such as a user’s password) with this method, while working against cookie-stealing and/or tampering?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Why bother?

    I wouldn’t use this technique for sensitive data. It can be useful in combination with a regular session though – you can give the client a cookie with a normal session id, but also include all those key/value pairs that your application needs on every page. This way, you can avoid hitting your session storage for every page request.

    You should aim to keep the amount of data pretty tight, since it will be sent with every request.

    With that in mind, onwards…

    Signing data with a hash

    If the data isn’t sensitive, you can sign the values with sha1 hash made from a combination of the key/value pairs and a shared secret. e.g.

    $values=array(   'user_id'=>1,   'foo'=>'bar' ); $secret='MySecretSalt';  $plain=''; foreach($values as $key=>$value) {     $plain.=$key.'|'.$value.'|'; } $plain.=$secret; $hash=sha1($plain);

    Now give the client a cookie with all the values and the hash. You can check the hash when the cookie is presented. If the hash you calculate from values presented by the client doesn’t match the expected hash, you know the values have been tampered with.

    Encrypting sensitive data

    For sensitive data, you’ll need to encrypt the values. Check out the mcrypt extension which offers a lot of cryptographic functions.

    Cookie theft

    With regards to cookie stealing, if you’re putting user credentials into a cookie and trusting it, then someone who obtains that cookie can impersonate that user until the password is changed. A good practice is to remember how you authenticated a user, and only grant certain privileges if the user explicitly logged in. For example, for a forum you might let someone post, but not change their account details like email address.

    There are other techniques for ‘autologin’ cookies, involving giving such cookies a token value which you only allow to be used once. Here’s a good article on that technique.

    You could also look at including the client IP in a signed cookie, and if it doesn’t match the IP presenting the cookie, you get them to log in again. This provides more protection, but won’t work for people whose apparent IP address keeps changing. You could make it an optional feature, and give the user a way to opt out. Just an idle thought, I’ve not seen that done in practice 🙂

    For a nice article which explains session theft, hijack and fixation see Sessions and Cookies which offers a few more techniques to try, such as using the User-Agent header as an additional signature.

    • 0