Re^2: 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

Replies are listed 'Best First'.
•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.	[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	[reply]
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.	[reply]