[Catalyst] New Auth/Session Stuff

[Wade.Stuart at fallon.com]

> Hmmm. There's nothing really wrong with Minimal per se. It's working out
> great for a small, one person app where only one user/password makes
> anything more than that overkill. It's really the security of the
> Session::State::Cookie that would be in question.
>

Little rant here, I am sure you know all of this, but some people reading
 the list may not understand it.

Session cookie does not hold any of the values for the session data,  So
you
are left with a magic token that syncs the client with the server session.

In any application that supports sessions over HTTP you have to make
assumptions about the session security.  The only two real concerns
usually are Session hijacking and session token guessing. Guessing is
easily evaporated when using large tokens that are virtually random
(md5, sha hashes).  Session hijacking via snooping the session
token is a more complex issue.  Firstly,  reduce the risk using cookies
instead of URI encoding wherever possible.  Next if you have moved to
cookies make sure the real for the cookie is well defined so that site to
site bleed does not happen. Also consider using SSL to encrypt the data
transfer (including session cookie).

One area where in your previous messages that I disagree with for most
apps is to use some sort of IP/auth/session tie.  It works in some
circumstances, but usually only when you control the entire environment.
It utterly fails when you expose it to the internet at large.  Many
organizations will have separate proxy servers or firewalls that round
 robin requests -- giving the server a new IP between requests on
the same session.  A prime example of this is AOL which is very well
known for jumping IP's on sessions (even though they are losing
market share they still have a large percentage of home users).

So,  if you need to secure the session use https, use cookie based
session tokens, timeout the session as frequently as you can while
still having useful UI.  Don't expose any information in the
session or app for that matter that you do not want the user
to have access to. Don't tie Sessions to IP addresses unless
you know for sure you have and will continue to have full say in the
whole layout of the network between end users and the app.