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?

  • Your first question on firesheep and the need for SSL has been covered before (Can you secure a web app from FireSheep without using SSL?) remember that in an active attack the attacker controls all the javascript that runs on the client, so no safe place to store the password. So please edit it out of this question.
    – nealmcb
    Apr 25, 2011 at 15:41
  • You might try emailing Ben Adida, the author of SessionLock. He might just respond here.
    – D.W.
    Apr 25, 2011 at 17:02
  • @nealmcb: that is not actually my first question. @D.W. thanks, I will. Apr 25, 2011 at 23:01

2 Answers 2


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.

  • Thanks, that makes sense. What about my second question: how does setting up a new session work when you lost the shared secret in the case that you don't use SSL? How do you couple the new session to the users identity without requiring him to enter his password again? Apr 25, 2011 at 23:24
  • 1
    Sorry I missed that second part. In that case, you would need to establish a new session ID and associated secret. You can do that with a Diffie-Hellman key exchange, but if you're trying to maintain some continuity with the earlier session, I don't think there's a way without SSL.
    – Ben Adida
    Apr 25, 2011 at 23:30
  • Thanks for your quick and to the point answers. That settles my questions :) Apr 25, 2011 at 23:36
  • +1 nice work, and thanks for stopping in! (Just out of curiosity, how did you happen to know to come here?)
    – AviD
    Apr 26, 2011 at 19:21

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).

  • Thanks! I'm still not sure. Why does the attacked need an active attack? Suppose the client logs in, establishes a secret with Diffie-Hellman, and then he loses the secret. At this point, we want the client to be able to set up the secret again, and be able to view protected pages again. On the other hand we don't want the attacker to be able to do the same thing, because only the genuine client should be able to view his own pages. What does the client have that the attacker doesn't have? Presumably the client didn't save the password on the client side, so the client has nothing? Apr 25, 2011 at 10:19
  • So how does the server differentiate between the genuine client and the attacker? The server should let the client do requests, but the server should not let the attacker do requests on behalf of the client. So somehow the server should be able to differentiate the client from the attacker. I don't see how that is possible without requiring the client to enter his password again. Apr 25, 2011 at 10:21
  • @jules I think the point is that you need to first establish the trust with real authentication via SSL. Sessionlock only preserves that authn, and only against passive attack.
    – nealmcb
    Apr 25, 2011 at 15:45
  • @nealmcb: the SessionLock paper explicitly mentions an alternative method without SSL. That's what my second question is about. Apr 25, 2011 at 23:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .