Slashdot Mirror
How To Protect Against Firesheep Attacks
Monday we mentioned Firesheep, a plug-in that trivializes ID spoofing on social networks. Since then various security researches have come out to suggest
How to Protect Yourself against Firesheep Attacks (submitted by
Batblue). Of course the advice is pretty obvious: Don't use free Wi-Fi, use SSL, or a VPN. It seems to me that the big sites should start by redirecting all non-SSL traffic to https automatically. If you want to be insecure, you'd have to explicitly state that you can't encrypt for some reason.
Open WLAN done by garbage WAPs do this. A decent WAP will not make it easy. Ones I install issue a complete seperate IP address and subnet for each connected person... It does not give you security, but it makes it far harder for script kiddie click and hack tools to actually find anything.
"Creates a separate virtual network for your wireless network. When this feature is enabled, each of your wireless client will be in its own virtual network and will not be able to communicate with each other. You may want to utilize this feature if you have many guests that frequent your wireless network."
It's called AP isolation and only a half assed install done by a n00b or wanna-be networking person does not have it enabled. Simply enabling this on a Open WAP castrates the firesheep quickly.
So it's only a problem at places where a complete idiot set up the wireless.
Do not look at laser with remaining good eye.
apologies, but "you're not using your servers" is a dump truck of horse shit. oh so our elastic cloud has free time, eh? electricity is now free? we dont know how to scale, how to utilize?
maybe if someone actually had quantified what kind of utilization end to end SSL required, you'd have half a leg to stando n. but citing google's use in this case means exactly what? you've cited a figure thats not an absolute value, so let me ask, 1% of what? you think their gmail servers are just dumping static text files over the network, that its 1% of almost nothing and thus SSL is free? or is there a chance those servers work their ass off, and they work so hard and do so much that what could be a colossal ssl task is margin error, simply because gmail is atlas, crunching the full text of your and 20GB account realtime with ease? it is impossible to do anything but guess, given your wishy washy proclamation.
last, maybe you have the budget to be running as many servers and to be hogging as much energy as you want, but what about all the mobile phone users connected to your site? is it acceptable that every single little AJAX interaction now has to go through the encryption/decryption straw on their 400 mhz oldschool mobile phone? what about places where, for various reasons, encryption is controlled or restricted? are we going to tell them no, unless you have full end to end encryption, you cant use the web?
the hubris of "just throw more end to end encryption" at it is bullshit, rotten wrong incorrect bullshit. what we need is a cookie solution not susceptible to man in the middle attacks. anything else is irresponsible overkill, and ignorant to the real problem and diverse requirements and use cases of the web. authentication does not have to be tied to end to end encryption, at least thats my mangled crippled understanding of Kerberos.