The case for server-side sessions tracking and Future Plans

["..hidden.." <..hidden..>]

Hi all;

I just wanted to clarify where I stand wrt server-side tracking and so
forth.  I will also describe how our solution will differ from Dieter's (we
both support some corner cases that are not generally in line with best
practices).  While I am open to other points of view, I think that we ought
to be able to agree quite quickly on 90% of this.

First, if you want serious web security, you simply cannot trust the
client.  Also, HTTP is stateless, so you have to understand that someone
could type in the exact same query string that gets you access to a
resource and get access to that same resource.  While there are some ways
of restricting this (by host or subnet), these break in environments where
one might want to host this and the customers might be behind arrays of
proxy servers (perhaps even spanning multiple redundant internet access
points).  So stateless authentication is not entirely an easy problem to
solve such that it works for everyone and provides sufficient security. 
Indeed it is expected that everyone will have something to complain about
regarding every possible fix.

As Chris Murtagh has pointed out on the SQL-Ledger list, this fix is
largely temporary.  I will refer to temporary fixes which stabilize the
application while structural changes are taking place as "scaffolding."  In
the long run, we agree that we need to have an open and extensible
authentication and session model that will allow people to use other means
for tracking this sort of thing.  Possible examples might include sessions
stored on the filesystem, in the database, etc. or the use of Kerberos as
an alternative (where the Krb5 ticket is the session to be validated), or
even X509-based authentication where the client cert is validated instead
of the session.  None of these options will work for everyone but if we
give people a choice, then they will be able to set things up to their
liking.

Expect more scaffolding to occur in the next couple of releases though this
should not have the same degree of impact on usage models that this does.

Now, our fix as of the next release will allow multiple logins with
different browsers against the same user account, but will restrict each
browser to one username.  From reading Dieter's fix idea, I think he may
support the other-- multiple usernames with the same browser, but only one
session per user.  But I am not sure as there is not enough information in
his post to be certain.  Currently, we are not planning on supporting
multiple usernames per browser because of possibilities of privelege
escelation.  I would like to see the application certified for credit card
processing (and am willing to invest some of my money to make this happen)
and so these things need to be paid attention to.

Anyway, I am open to discussion on any of these things.

Best Wishes,
Chris Travers

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .