Session theft?

"Gordon Burditt" <gordonb.65c56@burditt.org> wrote in message
news:cq78c8$l21@library2.airnews.net...
>
> There was supposed to be only a short timing window where one counter
> but not the other was incremented, but it managed to hit that window
> to drop modem carrier or whatever caused the out-of-sync problem
> often enough that using session counters proved to be a real nuisance.

I don't know about the specific system in question, but one way to avoid
that problem, if you have counters advancing in realtime (as opposed to
advancing per-request), is to allow the next or previous response as well as
the expected one. You would simply have to ensure that there is also a
requirement that the same response not be allowed twice, to avoid replay
attacks.

You can even allow a greater margin of error than this, and allow both
timers to resyncronise themselves should the client drift out of sync with
the server. That way the client would need to make no requests for a long
time before any clock syncronisation problems made the two so far out of
sync that the server would refuse to recognise a valid connection.

Given enough entropy in the system, reducing that entropy by say, 5-10 to
allow for this sort of dynamic re-syncronisation, should still be high
enough that the system is secure against attackers.

- Robert