Question about the SessionLock paper

Question

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?

Answer 1

Technically, you could use the password as the shared secret in SessionLock, but then the web site needs to store the password in the clear. So, as you suggest, you could use the password hash, but then the password hash suddenly becomes almost as good as the password itself, since knowing it is sufficient to set up a secure session with the server. So that's a pretty good reason not to use the password hash.

But mostly, my design goal, in SessionLock, was to not entangle the method of authentication with the security of the session. What about before you're logged in? I still don't want someone stealing my session. And what about on systems that use HTTP auth, or some other password-storage-and-checking abstraction that generally makes it difficult for your web app code to get at the password data, even its hash? Or a larger web site where login happens at login.*.com, and then a session cookie is set and that's it, the various service1.*.com, service2.*.com don't have the actual password.

For all of these little reasons, SessionLock doesn't tie its shared secret directly to the credentials.

And as other commenters mentioned, be careful. SessionLock only prevents passive network attackers from stealing your session. The payload is still readable by eavesdroppers, and you're out of luck against active network attackers.

Answer 2

Diffie-Hellman is sufficient to establish a shared secret out of thin air if you're not worried about active attacks, and according to the paper they make no claim to defend against these. So you're correct, the attacker can do the same, but only with an active attack, not simply by eavesdropping.

The protocol is vulnerable to active attacks generally anyhow, aside from this, it seems to me (e.g. the client engine is served up using JavaScript, which is not authenticated, so therefore you can introduce your own code and subvert the whole thing).

As to the other part of your question, why agree a new secret when you've already got one, it makes sense generally to avoid using a password directly as a key if you can, as the result is likely vulnerable to dictionary and brute force attacks. However in this case they have probably done it that way because an active attacker can steal the secret (though it seems to me they still can because of the JS problem I mention above).