Timeline for Why doesn't the Stack Overflow team fix the Firesheep style cookie theft?
Current License: CC BY-SA 2.5
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 17, 2016 at 22:08 | comment | added | user2284570 | @user153246 : I know lot of peoples who consider that websites which can’t display anything javascript are for malware. | |
| Jan 4, 2011 at 3:27 | comment | added | nealmcb | @rook: yup - it would need to be secure all the way, I've seen no evidence it could be made secure, and there be dragons at all turns.... Plain SSL would surely make more sense. Thanks for helping clarify this stuff. | |
| Jan 2, 2011 at 18:45 | comment | added | Rook | @nealmcb your solution makes the attack window smaller. There is still the problem of loading the html/js to begin with. If there where a way to sign this content then this solution may hold water. But as it stands if i protocol is insecure at any step, it is unusable. | |
| Jan 2, 2011 at 6:41 | comment | added | nealmcb | @rook yes - we agree this is certainly no substitute for ssl, and overall a foolish direction to go at best. I'm just curious to know if the server with html5 could prevent the MITM from stealing a reusable session identifier. Not that that would help the user very much given all the stuff an MITM could still get away with. And I was just clarifying that the proposal here didn't "transmit the secret in plain text", even though most likely the MITM could also pry it out of the browser as noted earlier unless html5 has good facilities to allow a great javascript programmer to prevent that. | |
| Jan 2, 2011 at 4:02 | comment | added | Rook | @nealmcb a message digest function cannot solve this problem. As the top answerer of cryptography questions on SO I'm telling you that SSL is the only solution to this problem, do not tell people otherwise. | |
| Jan 2, 2011 at 1:39 | comment | added | nealmcb | @rook - Q is only in the browser, fresh for each request, not sent over the network. A MITM attacking the javascript sent to the browser is a clever idea - I wonder if it is possible in the browser to somehow rely on javascript sent in the initial secure session, saved in local storage via HTML5. But I agree - at best a pretty risky, fragile and tenuous proposal. See more discussion at security.stackexchange.com/questions/1322/… | |
| Jan 2, 2011 at 1:17 | comment | added | nealmcb | Intriguing. Though this does not fully protect against a MITM attack since the attacker can just pass along the value for SHA1(Q+R), and do anything else they want with the request. | |
| Dec 10, 2010 at 9:18 | comment | added | Arjan | But how would that secret number R be stored in the browser for subsequent requests...? | |
| Nov 17, 2010 at 17:14 | comment | added | Rook | You need ssl and don't let anyone tell you otherwise. | |
| Nov 17, 2010 at 17:13 | comment | added | Rook |
-1 you're transmitting the secret used in a MAC in plain text, thus defeating the whole point of MAC. Further more, if the hacker can modify html and javascript used to generate the page and thus obtain your secret Q. Don't build security systems, this suggestion is horrifying.
|
|
| Nov 8, 2010 at 16:47 | comment | added | user153246 | Ah, well there's not me using StackOverflow much. Actually at all. The solution allows only the original login to be done over SSL but the rest to be done over HTTP, which is a lot cheaper than moving the whole site to use SSL. But yes, it still needs the initial connection to be done via SSL. | |
| Nov 8, 2010 at 16:45 | comment | added | heavyd | SO never use SSL, not even for the login process. They rely on a 3rd party OpenID provider to handle the secure login, so your solution still adds a new SSL piece to the mix. | |
| Nov 8, 2010 at 16:38 | comment | added | Aarobot | So the way to prevent using SSL is... to use SSL? I don't get it. | |
| Nov 8, 2010 at 16:18 | history | answered | user153246 | CC BY-SA 2.5 |