Re: Replay attacks with cookie session

Brad Ediger
2007-03-21T23:45:55Z

That''s essentially what a nonce is, but:

1) Nonce is random and can''t easily be guessed
2) It still doesn''t solve the multiserver problem: how does one
server know what the current version number is when there are 10
Mongrels?

On Mar 21, 2007, at 6:28 PM, Sandofsky wrote:

>
> 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
>
>
> >