[ic] New SecureProtect directive to prevent sidejacking

Peter peter at pajamian.dhs.org
Sat Oct 30 04:01:32 UTC 2010

On 30/10/10 16:51, Mike Heins wrote:
> Quoting Peter (peter at pajamian.dhs.org):
>> On 30/10/10 11:28, Josh Lavin wrote:
>>> New SecureProtect configuration directive (sidejacking fix)
>>> Author: Mike Heins
>>> This is a defense to "sidejacking", the collection of a session cookie
>>> by a host on an unsecure network. When SecureProtect is active, the
>>> UserDB login process creates a passhash of the encrypted password. This,
>>> along with username, login_table, and a "secret" set in the
>>> configuration, is used to check subsequent secure accesses to the catalog.
>> This is great.  I've been wanting to implement something like this
>> myself for ages but just haven't had the time.
>> I take it that this only protects the session for secure pages, so if
>> you implement this you should make sure that any important input or
>> sharing of private details happens on a secure page (via the
>> AlwaysSecure and ExtraSecure directives)?
> You also need to have a logged in status to be protected. Obviously
> you couldn't get to a secure login page otherwise....

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?


More information about the interchange-users mailing list