[WEB SECURITY] standards for session tokens

Billy Hoffman Billy.Hoffman at spidynamics.com
Fri Dec 1 16:48:42 EST 2006


Brian> The scalability penalty is in needing to maintain
Brian> the session store on the server.

Randall> I agree that this is an issue, but not I think a
Randall> deal-breaker. Starting from the given that
Randall> sessions are very useful, a little extra horsepower
Randall> on the server seems a good trade-off.

I've seen the solutions for using a database to store session info when
you have multiple server behind a round robin load balancer, geo
location + DNS magic, etc. How well do these things actually work with
big applications? And is that even really an issue? Maybe I'm missing
something here (it is almost 5 on a Friday :-), but outside of massive
e-commerce sites how many other applications need to store a lot of
session data *and* have massive user loads?

Billy Hoffman
--
Lead Researcher, SPI Labs
SPI Dynamics Inc. - http://www.spidynamics.com
Phone:  678-781-4800
Direct:   678-781-4845

-----Original Message-----
From: Randall Hansen [mailto:randall at raan.net] 
Sent: Friday, December 01, 2006 1:33 AM
To: Web Security
Subject: Re: [WEB SECURITY] standards for session tokens

On Thu, Nov 30, 2006 at 09:43:44PM -0500, Brian Eaton wrote:

> The scalability penalty is in needing to maintain the session store on
> the server.

I agree that this is an issue, but not I think a deal-breaker.
Starting from the given that sessions are very useful, a little extra
horsepower on the server seems a good trade-off.

> The reliability penalty comes when you start worrying about server
> failure.

I'd trust a server under the control of a good sysadmin much more than
a user's browser cache.

> Maybe even shared across applications written in different
> languages, by different people?

With a little work, this is possible today.  Not across different
servers, but OTOH a cross-server API to encrypted client-side
credentials would be an irresistable attack vector.

> Something that could be reviewed, attacked, improved, and eventually
> widely deployed and widely trusted?

I think that's a nice idea, but the bottom line is that storing
encrypted credentials on the client requires trusting that client.
That's the root of many security problems, and is IMHO intractable.

r


----------------------------------------------------------------------------
The Web Security Mailing List: 
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]



More information about the websecurity mailing list