Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

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

by EvdB (Deacon)
on Jun 29, 2004 at 15:27 UTC ( [id://370505]=note: print w/replies, xml ) Need Help??


in reply to Re: Is this a secure way to prevent cookie tampering
in thread Is this a secure way to prevent cookie tampering

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

Replies are listed 'Best First'.
Re^3: Is this a secure way to prevent cookie tampering
by hardburn (Abbot) on Jun 29, 2004 at 15:47 UTC

    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.

      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

        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.

        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://370505]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (4)
As of 2024-03-29 08:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found