[ic] New SecureProtect directive to prevent sidejacking

[Josh Lavin]

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.

For background see: http://en.wikipedia.org/wiki/Session_hijacking

Essentially, it stores the passhash in a secure cookie. When the regular 
session cookie is next accessed, if the secure cookie hash does not 
match the server-generated hash, then the user is sent to the login page 
(defaults to this). A "destination" parameter (defaults to this) is 
passed with the URL of the original request, so you can redirect them 
back to it once they have re-authenticated (via mv_successpage and the 
like).

Here is the commit for the latest:
http://github.com/jlavin/interchange/commit/662413756b9d80079e0b467caf9e85ed4ba15e00

And here is one against 5.6 STABLE:
http://github.com/jlavin/interchange/commit/325749624cc9a1bbafda90e9914c64fbfbcab81f

To test, enable in catalog.cfg, login on a secure page, delete your 
secure cookie (but leave your session cookie), then visit a secure page. 
You should be asked to login (or whatever "page" is set to).

I haven't figured out how to edit documentation, so following is a POD 
(also attached).

--------

=head1 NAME

SecureProtect

=head1 Synopsis

In catalog.cfg:

     SecureProtect   active  yes
     SecureProtect   secret  VerySecureYESIAM

=head1 Description

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.

=over

=item active

Yes or No (or any Interchange YesNo value) to determine if SecureProtect 
is used. Default: no

=item page

The interchange page to relocate to. Default: login

=item secret

The "secret" hash to add to usename and other key values for security. 
If you change this, all your users will have to re-authenticate at a 
secure page. Change the default value, please.

=item keys

The session values to hash with the "secret" to build the hash value. 
Default is
username,login_table,passhash.

Shouldn't need to be changed, do so at your own risk.

=item destination

The CGI variable name to store the previous page ($CGI::path_info) in. 
Used to generate a redirect to the original destination upon 
re-authentication.

=item authexpire

The amount of time (in Interchange duration, ala SessionExpire) that you 
will allow one hashing to last. Default is 7 days. After that time 
without logging in, the user will be forced to re-authenticate.

=back

=cut


-- 
Josh Lavin
Perusion -- Expert Interchange Consulting    http://www.perusion.com/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: SecureProtect.pod
URL: <http://www.icdevgroup.org/pipermail/interchange-users/attachments/20101029/5f5ea9e4/attachment.txt>