Re: Replay attacks with cookie session

Brad Ediger
2007-03-23T00:51:26Z

On Mar 22, 2007, at 7:27 PM, Jeremy Kemper wrote:

>
> On 3/22/07, Brad Ediger <brad@bradediger.com> wrote:
>> 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.
>
> Avoiding a single database lookup isn''t the purpose of the cookie
> store.

Sure, but you do remove a lot of the glamour of the cookie store if
it has to be tied to a database for a nonce lookup anyway.

>> 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.
>
> This discussion skipped plugging the session replay hole. I understand
> your concern, but I think you underestimate the average Rails
> developer.

I might be over-concerned here, but I''m not talking about the average
Rails developer. I''m talking about the worst ones. I can tell you
that while the average Rails developer I''ve worked with would
certainly be able to understand this and work around it, I''m not sure
that the worst ones would even understand what the issue was if it
were explained to them.

> For example: to prevent user_id replay, store a last access timestamp
> in session that''s updated on login and logout.

If I understand you correctly, you would also keep a copy of the
latest timestamp server-side. I would submit that for many
developers, storing a timestamp for each session on the server is not
much more attractive than just storing the whole session on the server.

be