BAROILLER Pierre-Emmanuel wrote:
I work with double cookie to add a "security"...
This is a common technique and does strengthen security somewhat.
You might want to consider using only one piece of session data rather than the whole thing. For example, many people who use this type of approach will have an extra validation key stored in the session that is used to create the second cookie (or URL variable or whatever).If the user try to change de sessionId, I check with the current sessionId stored into my own cookie.. But.. It may not to be usefull... :) The cookie is basically a crypted copy of the session content (with a different encryption method).
If you focus too much on strengthening security, or make your extra steps too complex, you risk making your session mechanism very inefficient, and this can open you up to the risk of denial of service attacks.
Not more efficient, but definitely a bit more secure.I'm looking for a good way to protect a private part of a site and... I was thinking this method would be more efficient than only the session cookie..
Here is a suggestion, however. Your method here is focused on preventing a "guess" attack, right? Well, the unique IDs generated by PHP are already extremely difficult to guess, and this is probably not the weakest point in your mechanism. What you might want to do is let your validation token be passed in the URL on each page. This way, for those with cookies enabled, the PHPSESSID will be in a cookie, and your validation token will be in the URL.
Why use two different methods? Well, there are more dangers than someone trying to guess a valid cookie. Browsers have been known to have vulnerabilities that allow people to read cookies from any domain (IE 4.0 - 6.0 has this problem). Thus, a bad guy could get a good guy's cookies and then visit your site. Passing a validation token on the URL certainly doesn't make everything safe, but it makes the bad guy have to work harder, and that's what we want to do. Also, with a combination of methods, you almost force the bad guy to have to intercept the HTTP request itself. If someone can intercept the HTTP transactions, then your only real protection is something like SSL, so if you're not using SSL, you can feel pretty good knowing that you've made things about as difficult for the bad guy as you can.
Happy hacking.
Chris
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
