Re: Replay attacks with cookie session

Sandofsky
2007-03-21T23:28:02Z

I''m not a crypto person, but what if a version number were embedded
with every write to the cookie session? Of course, check the data
+version against a hash to make sure they didn''t tinker with the
version.

On Mar 21, 2:26 pm, "Jeremy Kemper" <jer...@bitsweat.net>
wrote:
> On 3/21/07, S. Robert James <srobertja...@gmail.com> wrote:
>
> > IMO, we need to rethink moving to cookie sessions by default, then -
> > if a core member hadn''t thought about, what can we expect
from
> > beginners? Last thing we need is a reputation for being weak in
> > security.
>
> I think that''s a bit sensational.  The cookie store has gone
through a
> couple of evolutionary steps already and is ready for more, if need
> be.
>
> > Before everyone responds: "It will help performance, and good
> > developers don''t store volatile data in the session,
anyway!" I''ll say
> > that we''ve seen lots of companies (who won''t be
named) sacrifice
> > security in order to gain out of the box performance or ease of use -
> > and it comes back to haunt them.  Secure by default, and let the
> > advanced users make it less secure to improve performance - not the
> > other way around.
>
> Let''s see a brainstorm of solutions and other potential
vulnerabilities.
>
> > > > This is normally solved using something called nonce - each
signing
> > > > includes a once only code, and the signer keeps track of all
of the
> > > > codes, and rejects any message with the code repeated.
>
> > > This sounds like something you could perform at the application
level.
> > I don''t think so - as long as step 2 (in my example) goes to
one
> > Mongrel, and step 4 goes to another, the attack succeeds.  I can try
> > repeatedly with a script until this happens.  The only way to protect
> > is to use a shared backend like the DB or DRB - but then
you''ve lost
> > the point of cookie sessions.
>
> To some degree. I''m sure there''s more to this, though.
I''m not a crypto expert.
>
> jeremy