Re: Replay attacks with cookie session

Sandofsky
2007-03-23T08:30:36Z

Pulling two IDs (session id + nonce) from the DB is better than
pulling 80k that could go in cookies. Why not include nonce in the
default, and if the developer wants the blazing speed (and
corresponding dangers), they can disable it?

On Mar 22, 5:51 pm, Brad Ediger <b...@bradediger.com>
wrote:
> On Mar 22, 2007, at 7:27 PM, Jeremy Kemper wrote:
>
>
>
> > On 3/22/07, Brad Ediger <b...@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