On 1/23/07, Platonides Platonides@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.