Re: Replay attacks with cookie session

Sam Bravard
2007-03-24T16:55:06Z

This is a basic distributed systems problem.  There is no way to do a
secure shared nothing approach on the client side without creating
server side tracking/coordination overhead.  I know cookie sessions
look simple and appealing at first but we''re trading scalable
simplicity (db store), for complexity. For security and reliability
some sort of token (timestamps or nonces) would have to be coordinated
across all server instances and it needs to be perfectly coordinated
to work effectively.

http://www.cs.vu.nl/~ast/books/ds1/toc.html  (chapters 5, 6, and 8 are
good backgrounders)

The downsides of the cookie approach:

*) It causes more lookups/coordination overhead on the server side.
You still need a db or distributed transaction coordinator lookup
(each server in a cluster needs to know some sort of cluster protocol
for token or timestamp management), so we''re not saving a db lookup
and have to maintain coordinator and recovery logic.
*) It puts state unencrypted in a client device we have no control
over (open to attack, reduces the usefulness of the store if we can''t
put anything we want in there and feel safe about it)
*) It puts state in an unreliable device (browsers crash - especially
firefox with a few add-ons ;) that would require recovery logic

What is so broken that requires all of this messy overhead and
limitations?

In my mind there needs to be an overwhelming pain to justify the cost
and I can''t see/feel the pain to justify this effort and wasted time
on the core list.

SamB


On Mar 23, 11:18 am, "Jeremy Kemper" <jer...@bitsweat.net>
wrote:
> On 3/23/07, Jeremy Evans <jeremyeva...@gmail.com> wrote:
>
> > On 3/23/07, Jeremy Kemper <jer...@bitsweat.net> wrote:
> > > Let''s talk about practical fixes rather than whether we
should write
> > > it off entirely.
>
> ...
>
> > > This requires one additional database query on logout to
invalidate
> > > future reuse of that session and no additional per-request
queries.
>
> > This assumes you are doing a query per request anyway, and basically
> > piggy backing on it for the security.  If your application is already
> > doing a query for the current user for every request, sure,
there''s
> > almost no additional cost.  However, if your application
isn''t doing a
> > query per request, you have to add one to get the security, which
> > makes the cost the same as using the database for session storage.
>
> That assumption is stated at the beginning of the example:
>
> > > An application-level solution to user_id replay:
>
> You reason that touching the database "makes the cost the same as
> using the database for session storage" which is likely wrong and
> certainly unsubstantiated.
>
> Criticism is great and welcome, everyone, but let''s add some
> creativity and code to the mix, please.
>
> > IMO, this is not a problem that the application developer should need
> > to deal with manually, any more than application developers should
> > handle database transactions manually.  If cookie based session
> > storage is going to remain the default:
>
> We all agree on this. We''re working on it.
>
> > 1) There should be a configurable timeout set automatically, with a
> > reasonable default (to partially mitigate the replay issue)
> > 2) It should be documented that replay attacks are still possible
> > 3) Advice on creating application specific solutions such as the one
> > you mentioned should be included in the documentation
>
> Good ideas.
>
> > Note that timeouts provide only slight additional security, as they
> > only protect against attackers who get access to a session cookie
> > after it has already expired.  If an attacker gets access to any
> > session cookie before it expires, they can keep that session open
> > indefinitely.
>
> Not in the scenario above: the legitimate user logging out invalidates
> the attacker''s session, which is the same behavior as a
server-side
> session.
>
> jeremy