BAROILLER Pierre-Emmanuel wrote:
I work with double cookie to add a security...
This is a common technique and does strengthen security somewhat.
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).
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 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.
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..
Not more efficient, but definitely a bit more secure.
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
