Re: Replay attacks with cookie session

Neil Wilson
2007-03-27T15:24:13Z

I understand the distinction very well. I would suggest that you have
ascribed more capability to ''session'' than the semantics of
that
facility allow.

What I''m saying is that now you have client side session data, you
have exposed the limited semantics of ''session'' and there is
an issue
that was simply masked by the server side stores.

Rails has never offered authenticated anything. That''s why there is no
standard login mechanism.

Why not switch to session side stores and mask the issue, or implement
an AuthenticatedSession that does what you want it to do (and release
it as a plugin if you so desire). Complex cookie encryption might be
an interesting technical puzzle, but is it really required by default?

It''s a question again of where the framework ends and the application
begins. I don''t believe that there is justification for foisting
complex default encryption mechanisms on the framework when the
''problem'' is that you are using the wrong model. Just use a
server
side session store.

Now I may be wrong about ''session''. Perhaps it is a much more
complex
object than it appears. Perhaps it should be. That is not for me to
decide.

NeilW


On Mar 26, 7:45 pm, Brad Ediger <b...@bradediger.com>
wrote:
> I''m not sure you understand the distinction here.
>
> We had server-side sessions before. We still do. They accomplish
> everything you are describing, without requiring every developer to
> implement an AuthenticatedSession object himself. Look into
> ActiveRecordStore in action_controller/session/active_record_store.rb.
>
> This discussion is about the recent move to sessions stored in a
> cookie, and how to secure such sessions. I would suggest you go to
> Google Groups and read this thread from the beginning to get the
> background.
>
> On Mar 26, 2007, at 1:35 PM, Neil Wilson wrote:
>
>
>
>
>
> > 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?-
Hide quoted text -
>
> - Show quoted text -