[ic] New SecureProtect directive to prevent sidejacking

[Peter]

On 31/10/10 01:56, Mike Heins wrote:
> Quoting Peter (peter at pajamian.dhs.org):
>> 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
>> denied.
> 
> That prevents the multi-day de-authentication scheme.

Oh, I see, you're mixing session protection with cookie login.  I'm not
sure that these should be combined as it seems to over-complicate
things.  What's wrong with just protecting the session and then making
the login cookie secure?  This would seem to be a much simpler approach,
would allow sessions to be protected regardless of login state and still
allows for automated login with cookies.

>>> 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.
> 
> That type of behavior doesn't make them a target for sidejacking.

I can imagine some scenarios where it is ... stalking for instance, but
regardless, who are we to say what personal data is worth protecting to
someone and what is not?


Peter