What kind of applications often need to update their already strong identifier? Banks, military sites, government sites, etc. If that is so, do you not think it is modest to ask for having JavaScript turned on?
Just create a JavaScript that calls after certain amount of inactivity. If the JavaScript is turned off, then there is no problems - "just" a degraded security.
André D wrote:unless you want the user to be logged out and lose his blog post.
You are thinking simplistically. Why to lose the content? A log out does not mean you lose anything. Use your imagination to "save" the content.
André D wrote:It's not a matter of standards, it's a matter of timing and the HTTP protocol. Going back to the problem I brought up in my first post in this thread, the more often you change the session identifier cookie, then the more users you will have that see this problem, no matter what browser they use. It's the good ole security vs. convenience tradeoff. My point is that if you change the identifier too often, then people are bound to run into this, and when they do they will perceive it as a bug in your application.
If they use a typical web browser with JavaScript turned on, no problems would occur except in really rare cases.
For instance, look at this:
Code: Select all
$data = str_repeat('1234567890',128);
echo "<script>document.cookie='session_id=new_id'</script>";
for ($a = 0;$a < 9;$a++)
{
echo $data;
flush();
sleep(1);
}
Now if you press the stop button on purpose, you will still have your cookies created. I even tried pressing the button quickly, but the cookies were still created, because the timing has to be so damn precise. How long does it take to send 20 bytes of data to the client? With a 512 kBps connection it takes around 0.0003 seconds (of course there are other things affecting it, but the number will not change much). And now, you have to press the stop button within that time and the button has to deliver the signal and actually stop the download. This is hard to achieve even on purpose not to mention by accident, but that is the price you pay for your high security bank website. You must tell your user that this bank site requires JavaScript, which I do not think is much to ask for. Actually we could almost assume the user has JavaScript. We are in 2009, simple JavaScript calls should be possible. If not, then the user has to enable them as it is the requirement for this very high secure site.
Obviously there are always situations where the cookies may not be updated. This also applies to the case you said earlier: regenerating the identifier after a password change. If I change my password and press then stop and go back, I have to login unless we are using my simply-demonstrated JavaScript method which can make this practically impossible.
And yes, ultimately there is no way to be 100% sure the cookie was updated.
I can see your point, but I assumed that the client has JavaScript turned on as very high secure websites rarely work in a limited environment.