I agree that using something like CGI::Session is the best way to go, but if you want to roll your own or understand why this problem is harder than it looks, here's a little explanation. There are two goals to session IDs: uniqueness and difficulty to guess.
You're pretty close on the uniqueness one; time and PID ($$) are the traditional way to get a unique token, since if your process is running at a particular time there can't be any other process with the same PID running. But I'm not sure why you're adding and XORing them together; something like join(".",time,$$) would work better, and be simpler. This technique breaks if the same PID is re-used in the same second---fairly unlikely to happen on a normal system with sequential PIDs, but it's more likely on a system with random PIDs, and can sometimes be forced to happen by an attacker, for example by making 65535 requests to your Web server in the same second. This technique will also fail if you're using persistent processes to handle Web requests, for example mod_perl.
If you're storing sessions on the filesystem, the inode number of the session file is guaranteed to be unique. You can get that with stat. If sessions are in a database, the database can probably give you some kind of unique token (like an autoincrementing field). These techniques should always work, unlike PID+time, which at best will almost always work.
As far as making session IDs hard to guess, your best bet is to use a truly random number, decide how hard you want to make your session IDs to guess, and then append that many random bits onto the end. Math::TrulyRandom along with the Entropy Gathering Daemon (or /dev/urandom if your OS supports it) are a pretty good way to get truly random numbers; using rand gives pseudorandom numbers that aren't suitable for protecting anything.
In reply to Re: Sessions with perl cgi
by sgifford
in thread Sessions with perl cgi
by wolis
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |