Re^3: Is this a secure way to prevent cookie tampering

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.

Comment on Re^3: Is this a secure way to prevent cookie tampering

Replies are listed 'Best First'.
Re^4: Is this a secure way to prevent cookie tampering by EvdB (Deacon) on Jun 29, 2004 at 16:01 UTC
You are of course correct that a truely random number would be secure. In fact my approach of ID + secret just moves the randomness to a different part. I prefer the id + secret route because it is easier to deal with in the database. The id can be a integer which the indexes like and the secret is just a char(30) or whatever. Having the id as an integer allows for easy referencing from other tables. There is also the cosmetic appeal of seeing how many sessions you have gone through... --`tidiness is the memory loss of environmental mnemonics`	[reply] [d/l]
•Re^5: Is this a secure way to prevent cookie tampering by merlyn (Sage) on Jun 29, 2004 at 16:35 UTC
Having the id as an integer allows for easy referencing from other tables. There is also the cosmetic appeal of seeing how many sessions you have gone through... Then just send your strong secret over the wire, and use a database table to map your strong secret to a simple session ID. That'll help you reject bad secrets faster too, or even make it possible to change the secret every minute without messing up the sessions. -- Randal L. Schwartz, Perl hacker Be sure to read my standard disclaimer if this is a reply.	[reply]
Re^5: Is this a secure way to prevent cookie tampering by iburrell (Chaplain) on Jun 29, 2004 at 16:37 UTC
You don't need to put the id in the cookie. It is acceptable to use the sequential integer id as the primary key in the database. Having a longer key is a good idea since it makes it harder to guess. You can send just the key in the cookie, and look that up to find the session.	[reply]
Re^6: Is this a secure way to prevent cookie tampering by exussum0 (Vicar) on Jul 01, 2004 at 02:32 UTC
I hope you mean sequential as in a sequence with hard to predict next values. It's better off to take noise from /dev/urandom or something like taht. Pregenerate the primary keys or something. But don't use a predictible sequence. Otherwise, guessing what someone else's session key is easy. Even if you are encrypting, if the encryption is broken, a random next number is harder to guess. Bart: God, Schmod. I want my monkey-man.	[reply]


Syntactic Confectionery Delight
	PerlMonks