Re: Replay attacks with cookie session

Neil Wilson
2007-03-26T18:35:35Z

The ''standard'' use is incorrect. I don''t believe it
has ever been put
forward as ''best practice'' by any serious modeller. All
I''ve seen it
in is in simplified tutorials. Are you sure it isn''t a case of truth
by repeated assertion?

You shouldn''t be storing ID references to the User model in the
session hash; you should be storing ID references to the
AuthenticatedSessions model.

That way when you click ''LogOut'' the relevant
AuthenticatedSession
object is deleted from the database, and then it doesn''t matter one
jot what the next persion does with the cookie.

If something doesn''t fit, then look to the model. You''ve
probably
missed a relationship that should be a first class model object.

On Mar 22, 5:15 pm, "S. Robert James" <srobertja...@gmail.com>
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?