Re: Replay attacks with cookie session

Brad Ediger
2007-03-22T18:16:45Z

This was discussed earlier in the thread. The problem is that such a
nonce would require communication between the backend servers via DRb
or the database, which removes any benefit from storing the cookies
client-side. You might as well store the whole session in the
database or DRb store.

As for the opt-in, if you''re the type of user that would know enough
about security to opt in to such a plan, you''re probably not storing
account balances in a client-side cookie. The discussion we are
having concerns sensible defaults.

On Mar 22, 2007, at 1:01 PM, Steve Longdo wrote:

> This problem can be addressed in a lot of ways.  One of the easiest
> approaches would be to use a filter to process the validity of a
> cookie.  Have an after_filter that adds a "single-use" token to
the
> cookie after a request and a before_filter that checks for the
> "single-use" token when a user makes a new request.  That way a
> replay attack wouldn''t work.
>
> Bundling in something like this into Rails makes a lot of sense.
> It would be opt in by adding the filters into application.rb and
> not forced on anyone by default.
>
> On 3/22/07, Brad Ediger <brad@bradediger.com> wrote:
>
> On Mar 22, 2007, at 11:15 AM, S. Robert James wrote:
>
> > On Mar 22, 10:44 am, Brad Ediger <b...@bradediger.com> wrote:
> >> This is the crux of the issue... of *course* it''s a
terrible
> idea to
> >> store sensitive or transient data in the session, but the
> question is
> >> one of API design. Do we want the penalty for ignoring best
> practices
> >> to be compromised security?
> >
> > It''s even more complicated.  Defining "sensitive or
transient
> data" is
> > not at all trivial.
> >
> > The standard use case for a cookie session is store only flash and
> > user id.  Not sensitive or transient?  Okay.
> >
> > Now, I click "Log Out", and get up from the
library''s computer, only
> > to let the person waiting after me to retrieve the old cookie....
> That
> > innocuous user id just became both sensitive and transient.
> >
> > The point is, answering these questions is hard.  Witness the
> > confusion in this thread alone.  DIY cryptosystems are hard:
> > professionals fail.  WEP failed.  Does it make sense to push all
> these
> > questions onto each new Rails developer''s shoulders?
>
> And I think that is exactly what it comes to. That''s kind of where
I
> landed with that post when I started considering what user_id really
> meant.
>
> As neat as cookie sessions are, I don''t think I''m going
to use them
> to store authentication info anymore. Too many question marks.