[paulbaumgart]

Would this work as a cheaper alternative to SSL for preventing session hijacking?

  1. During the HTTPS part of the communication,
     the server sends a long list of random strings.
  2. The client stores all these strings in localStorage.
  3. On every request, the client sends one of the strings
     from the list, the server validates that it is in fact
     a valid string for that session, and both remove that
     string from their lists.
  4. When the list runs out, you have to go back to SSL to
     exchange a new list of strings.

Is there a flaw I'm overlooking (beyond the reliance on localStorage) that keeps people from using this?

If not, is there a technical term for this technique so I can Google it?

[caf]

Even better:

    1. During the HTTPS part of the communication, the server generates a single
       random key and sends it to the client.
    2. The client stores this string in local storage.
    3. For every request, the client generates a HMAC over the request parameters
       (including a monotonic sequence number) using the key.

Both of these schemes are still susceptible to a MITM, who can just insert a bit of javascript in any page received over HTTP, that reveals the temporary secret in local storage to anyone listening.

[paulbaumgart]

If you were to generate the HMAC over the entire request, would that help with ensuring authenticity?

[electrum]

It wouldn't be vulnerable to JavaScript if it was built into the browser -- like HttpOnly cookies.

[jgrahamc]

That's essentially a one time pad where you are using SSL for pad distribution.

[caf]

It's not a one-time-pad, it's a one-time-password system.

(Just like the SAS codes that are used by STRATCOM to authenticate nuclear launches! ;)

[nodata]

How does this prevent a MITM attack?

[paulbaumgart]

It doesn't. Is it possible to do a MITM attack on the person at the neighboring coffee-shop table?

The only way I can think of involves being really clever about timing and being physically between the other wireless client and the AP: create enough interference to prevent their transmission from getting through to the AP right after you read the transmission, then quickly forge a request using the same one-time key.

Of course, if someone has access to the packets upstream from the AP, you're always hosed if you're not using encryption. This certainly isn't meant as a replacement for AES. :)

[jgrahamc]

Is it possible to do a MITM attack on the person at the neighboring coffee-shop table?

Yes. You can attack ARP or DNS to take control of their connections.

[pmjordan]

DNS (the UDP responses are easy to forge) is a great way to do it. You just have to be faster than the real DNS server, which might be tricky if it's local and caching.

For ARP-based attacks you'd presumably announce yourself as the owner of the default gateway's IP address, routing all data through your system.

Hijacking DHCP springs to mind; respond with an address on a completely different subnet, and your system as default gateway. Again, jackpot.

You could also install a rogue wireless access point with the same SSID, which would let you route all traffic through your system. You just need people's devices to pick yours over the real one, which would presumably require yours to have a stronger signal.

All of the above let you install a transparent proxy which gives you complete control over the target's browser's security context.

Interestingly, the rogue access point would even work with WPA(2)-PSK encrypted wifi, if you knew the key.

[paulbaumgart]

Great points. It's impressive how elegantly SSL with a CA solves all these problems. :)

[nodata]

So what was your suggestion was for then? I think I'm missing the use case.

[paulbaumgart]

Taking write access to my Facebook account away from anyone who captures my wireless packets on their way to the AP.

[nodata]

But that's the part of the connection we are worried about. End to end encryption from the client to the website is needed. I still don't see where your idea comes in. Clearly I'm not understanding something.

[naz]

Yeah you would need to hash the contents of the request against the one-time string and then send the hash but not the string.

[chrischen]

That's kind of like refreshing the session key on every page request except you send over a list of session keys that will be used on subsequent requests. Probably not done since it's usually a hit to the session storage on every page request. Still doesn't encrypt the actual content though, and since SSL would encrypt it and make this unnecessary that's probably why it's not done.