[ic] New SecureProtect directive to prevent sidejacking
peter at pajamian.dhs.org
Sat Oct 30 05:14:10 UTC 2010
On 30/10/10 17:13, Mike Heins wrote:
> Quoting Peter (peter at pajamian.dhs.org):
>> Why do we need to limit it to logged in users? Why can't we protect
>> secure pages in the session before someone is logged in?
> Nothing stops you from generating your own MV_SHASH via another
> process. Feel free.
> But what information would you base the hashing on? We can't use IP
> address or MAC address, if they are sniffing. Session keys are kind of
> pointless -- if you did that you would only be protected on
> the *second* page. What's the point?
What about just a random token stored in the session itself? If the
secure cookie has the wrong token or non-existent then secure access is
> And why would you put secure information in a session before someone
> authenticates? In normal operation, you don't want to use SSL, and
> why waste CPU cycles on a random non-authenticated user?
Someone can go right through to checkout without logging in, and even
complete checkout as a "guest" (albeit with an implicit login).
Certainly a good deal of data can be accumulated just from the browsing
habits of the user, what items they add to their cart, etc. before they
login. On a multi-page checkout there is even personal telephone and
address data that is stored and can be retrieved, and all before the
customer has to login.
More information about the interchange-users