Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

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

by EvdB (Deacon)
on Jun 29, 2004 at 15:32 UTC ( #370510=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

I am using the session_id to brand the browser, with the session_secret to prevent attackers from guessing a valid session_id. The reason behind all the anti-spoof stuff is to allow the initial checks on the cookie to be confident that the client database_id is actually correct. This allows the script to try to connect to the client's database directly instead of having to have to refer to a lookup database on each request.

Once the client database has been connected to the session details are validated as well.

--tidiness is the memory loss of environmental mnemonics


Comment on Re^2: Is this a secure way to prevent cookie tampering
Download Code
•Re^3: Is this a secure way to prevent cookie tampering
by merlyn (Sage) on Jun 29, 2004 at 16:24 UTC
    The "session_secret" isn't buying you a thing. Think about the attack vectors. If someone has the session_id, they also have the session_secret, since they got it by sniffing. If someone can guess your session_id, you didn't use a strong enough ID. Just put more bits into one value: no need to separate it into two values.

    Simplify your life. Just use a session_id. That's enough.

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

Re^3: Is this a secure way to prevent cookie tampering
by waswas-fng (Curate) on Jun 29, 2004 at 16:34 UTC
    Thats the point, stash the sensitive information on the server side and use the session ID as they key to retrieve it. The actions should look like this: User connects to application, app auths user, on successful auth app gets a list of all access levels the user has permission to use. The info is cached into the session. only the session ID is sent back to the user's web browser. on future requests from the user, your app takes the Session ID from the cookie and retrieves the auth/access info from the local (server side) session store (keyed off the session ID). get it now?


    -Waswas
Re^3: Is this a secure way to prevent cookie tampering
by Anonymous Monk on Jun 29, 2004 at 19:16 UTC
    I, personally, prefer a hybrid solution. First, guessing of keys will always be possible for a user who can ascertain their length. The possibility of them guessing correctly is low, but as you begin to use up possible keys it will inrease. In solutions I use, I tend to have honeypot sessions, unused, that if accessed ban a user temporarily. That takes care of random guessers who try to bruteforce.

    I also log at a basic level users attempts to login (by ip). It's my responsibility as an administrator to decide if a user is attempting to hack the site, or is having genuine problems.

    Furthermore, I _do_ use two session IDs. One of those session IDs is only used securely, though, by setting the cookie to encrypted. That session ID is used for higher level authentication procedures.

    Even moreso, for anything that involves money, or purchases I require users to input their passwords if their session wasn't created recently.

    That keeps sessions pretty damn secure.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (15)
As of 2014-09-02 19:14 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (29 votes), past polls