A cookie should store only a randomly-generated unique ID
Are you suggesting that I should rely on the randomness of the ID to prevent spoofing. Surely storing a serial ID and also a secret unique to the session would be better.
There are also issues with your approach such as the complexity of checking that the ID is unique and also generating unique numbers when the available pool is largely used. Admittedly these would not be issues for low traffic but they do exist.
--tidiness is the memory loss of environmental mnemonics
| [reply]
[d/l] |
Are you suggesting that I should rely on the randomness of the ID to prevent spoofing.
Yes. If it is truely random, you don't have to worry about it. It won't stop replay attacks, but nothing besides strong encryption of the entire session will (such as HTTPS).
. . . complexity of checking that the ID is unique . . .
This is as easy as telling your database that the session ID field must be unique. A decent database will do the rest for you.
. . . generating unique numbers . . .
Random number generation is a hard problem, but not unsolveable. You benifit from the fact that a lot of people have already studied the problem and implemented solutions. My prefered way is to get some ammount of data from a cryptographically-secure random number generator (like /dev/random) and then put it through a hash (SHA1 prefered; pretend MD5 doesn't exist). SHA1 will then give you a 160-bit value which you store in your database and the user's cookie. That gives you 2**80 possibilities before you can expect keys to collide (due to the Birthday Problem). If you get one visitor per second, you can expect this to happen sometime around the time when the universe can't hold itself together anymore because all the usable energy has been converted to heat. (Of course, this assumes a good RNG).
----
send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.
| [reply] |
| [reply]
[d/l] |
