4 ms·
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
by paulbaumgart 16y ago
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?
- jgrahamc 16y agoThat's essentially a one time pad where you are using SSL for pad distribution.
- caf 16y agoIt'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! ;)
- chrischen 16y agoThat'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.
- nodata 16y agoHow does this prevent a MITM attack?
- paulbaumgart 16y agoIt 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. :)
- nodata 16y agoSo what was your suggestion was for then? I think I'm missing the use case.
- paulbaumgart 16y agoTaking write access to my Facebook account away from anyone who captures my wireless packets on their way to the AP.
- nodata 16y agoBut 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.
- deleted 16y ago[deleted]
- jgrahamc 16y agoIs 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.
- 16y ago
- naz 16y agoYeah you would need to hash the contents of the request against the one-time string and then send the hash but not the string.
- caf 16y agoEven 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.
- electrum 16y agoIt wouldn't be vulnerable to JavaScript if it was built into the browser -- like HttpOnly cookies.
- paulbaumgart 16y agoIf you were to generate the HMAC over the entire request, would that help with ensuring authenticity?