Not sure how many people here actually do programming, but this technique is applicable to all web languages. I'll be focusing on PHP in this particular example though.
When writing website systems, there's generally a few rules of thumb that you want to always follow. First, you want your users data to be secure and second, especially on high traffic sites, try to offload anything you safely can onto the users browser.
Now, some people who have used things like PHP sessions are probably using it wrong. First and foremost, with ANY session system, it's usually horrible practice to store a ton of information in the session. Generally, you want to store only id's and use that information on your backend to reference the data. Never, ever, ever store the data directly in the session. Simply put, when you start relying on doing such a thing it can end up giving you unintended consequences later down the road.
The easiest example I think I can give for this would be something like user profile information. Say after you log in a user, you decide that to keep things easy you'll just store all their profile information into their session. In things like PHP the session data is read/written to the disk (or database) each and every page load, sometimes multiple times per page load depending on how you write your system. Not only can this kill your sites performance, when you start getting more and more data it can also cause unexpected issues. For instance, one day you decide to change the session handling to store the information in a database rather than the file system, but you start getting errors because information is being truncated off and corrupting the session data itself.
The simplest way to avoid something like that is simply don't do it. It's bad practice anyhow.
Now, another nice trick, is storing the session information on the users browser in a cookie. This gives you a few advantages. Not only does it significantly simplify your session handling, it makes it so you no longer need to store/retrieve this information from a database or file system. This is best done when you are actually properly using sessions in the first place (rather than storing all the users information, store just the user id and use that to reference the users information later only when you actually need it). However, you can't just store something like a user id and hope that you won't have malicious users spoofing information.
But there is a way, and it's actually quite simple. By using something like a server-side secret value (usually something extremely long and extremely random), and hashing functions you can safely place such a thing into a cookie and make it impossible to "easily" crack (by that I mean, no encryption in the world is 100% totally unbreakable).
First of all, you'll need a non-changing secret key in your application. Something which you never, ever, distribute out to anyone (it'd break any security you add to do so). For this example, I'll be using a random SHA1 hash, but you'd likely use something a little stronger.
Secret: 2bffd564c0979f5d4bf68ab630c5234fb38b3493
Now, say you have a user log into your site. We'll say that this particular user's id is 54.
Now here's where the magic comes in, you need to generate a cookie value using your secret value, the users id, and some random seed value that you'll generate on the spot now. So lets generate our seed:
Seed: 9389552
So we now have a seed (randomly generated for each new cookie), a user id, and a secret key. Lets make a cookie (for this demonstration I'll be using SHA1 one-way encryption, you may substitute this with any other method you wish, such as SHA256).
The basic formula for this is:
UserId + '-' Seed + '-' + SHA1(UserId + Seed + Secret)
which for this case would end up being:
54-9389552-5fd41536bfb364e6fec7922297f041f13445eea8
This here is the value you would store in the users value within your cookie. But this is only the first half of it. You'll need to read and validate the cookie too. So here we go (I assume people know how to read/write cookies who have gotten to this point).
First, if the cookie is set, read in the value. In this case the value of our cookie was "54-9389552-5fd41536bfb364e6fec7922297f041f13445eea8".
Now, split the cookie up so you have the user id, seed, and generated sha1 value:
uid = 54
sed = 9389552
hsh = 5fd41536bfb364e6fec7922297f041f13445eea8
At this point you have all you need to make sure that this cookie is valid to allow access for user 54 to the user. Simply compare the hash with another hash generated using the same method above:
If 5fd41536bfb364e6fec7922297f041f13445eea8 EQUALS SHA1(uid+sed+Secret)
then your id is valid, otherwise they're spoofing and you can handle it however you want to.
