Some time ago there was a big fuzz over Firesheep: by listening to wifi traffic your login session can be stolen which is very bad because now somebody can e.g. send emails on your behalf. Some people said that using SSL for the whole site was the only solution. But I didn't think this was true: if you can keep the password or equivalent stored on the client side, and you never send this to the server but rather authenticate every request you do with this password, then nobody can impersonate you (unless they know your password). For example when you do a HTTP request
req, you instead do the request
r + "?hmac=HMAC(password, req)" to prove that you know the password.
Then I came across a paper on a protocol called SessionLock, which is targeted at solving the same problem. It is a bit different than what I described above, and I have some questions about it.
First, why do they establish a shared secret over SSL or using the Diffie-Hellman protocol, when there already is a shared secret available (the password or a hashed version of the password)?
Second, about the version that uses Diffie-Hellman they say:
If the browser loses its secret, it can re-perform a Diffie-Hellman key exchange with the server, using a number of XMLHttpRequest calls.
Can somebody explain how this works? Supposedly the client side didn't save the password, and it also lost the shared secret. So as far as I can see the client side knows nothing, yet he is able to re-establish a shared secret that can be used to do authenticated stuff. Wouldn't an attacker be able to do exactly the same? What am I missing?