On 1/23/07, Platonides <Platonides(a)gmail.com> wrote:
A session cookie will expire. A password probably not,
would allow to
change password, etc.
Yes. Session cookies don't also let someone get into your bank account
(true for many folks).. etc.
It could be less acceptable to normal users if each
time they switch on
their computer had to type their password :S
True.
Ideally, that sesion cookie would be a shared secret
stored by the
browser, used to compute the (edit) tokens.
AFAIK this is unfeasible as today, unless you force a custom browser.
All we need to do is add a kerberos agent to the browser.... and.. :)
Actually, JS can read and cookies, and thereby use them as a
datastore. Based on prior threads about JS based challenge
response... it would actually be possible to do this.. but only with a
ton of JS hackery. (I.e. client side JS computes
cookie=H(uid+password) and stores it as a cookie server also stores
this, server would occasionally challenge the client to compute
H(cookie+counter) ... but without server authentication there is no
way to prevent an active MTM attacker from using the client as an
oracle).
Another approach could be changing the session cookie
too fast (e.g.
each 3-4 requests), so a cookie theaft couldn't reuse an old cookie.
As I said before.. SSL makes it all the issues go away. As a long
term project we should probably figure out how to make SSL work for
us, and not waste time with hacks. Any other path will result in us
reinventing SSL poorly.