Firesheep: Easy HTTP session hijacking from within Firefox

Post by kabuks » Tue, Oct 26, 2010, 4:46 AM UTC

jberryman wrote: post #224

ramanujan wrote: post #154

There are probably going to be a lot of people negatively affected by this for quite some time to come. One thing to point out is that there are grades of things. There is "public", and then there is "top hit on Google". Similarly, there is "insecure" and then there is "simple doubleclick tool to facilitate identity theft". How many millions of dollars and man hours is it going to take to lock down every access point…

America was a better place when people could keep their doors unlocked I hate this mythical "good old days" B.S. I know people who live in the country who don't lock their doors because they live in the country. The idea that people who lived in urban areas ever could leave their doors unlocked is absurd.

Post by zemaj » Tue, Oct 26, 2010, 5:24 AM UTC

xorglorb wrote: post #248

cheungpat wrote: post #118

Earlier quoted context omitted.

There is so many hoops I have to jump to make this work in OS X. $ mv firesheep-backend firesheep-backend.binary $ cat > firesheep-backend #!/bin/sh sudo /path/to/firesheep-backend.binary $@ ^D $ sudo chmod +x firesheep-backend Then restart Firefox and start capture. You need to run sudo once every certain period.

I keep getting a "Failed to fix permissions" error. Any insight into that?

Post by pak » Tue, Oct 26, 2010, 6:12 AM UTC

Groxx wrote: post #315

pak wrote: post #310

Earlier quoted context omitted.

People bring up the Google stat, but you have to remember they have incredible engineering resources so they probably optimize in many features every day without adding additional machines. That doesn't mean every dude with a LAMP stack out there can turn on SSL and expect the same performance, just that it's possible with mongo manpower and talent to make it work. (Google doesn't even release the details of their we…

How many web servers do you know of which are CPU bound, and not through massive code stupidity, and not I/O (in some manner - waiting on SQL, disk access, bandwidth)? Encryption can run while other threads are waiting for a response. In general , it's a negligible cost; it adds a very minor delay compared to latency / transfer time, and uses CPU otherwise highly unlikely to be pegged. If you're pushing threading lim…

Post by wh-uws » Tue, Oct 26, 2010, 6:55 AM UTC

Encosia wrote: post #254

jberryman wrote: post #224

Earlier quoted context omitted.

America was a better place when people could keep their doors unlocked I hate this mythical "good old days" B.S. I know people who live in the country who don't lock their doors because they live in the country. The idea that people who lived in urban areas ever could leave their doors unlocked is absurd.

I live in a suburb of Atlanta and haven't locked my front door during the day in about a decade (since moving from an apartment to a house). The world isn't really as scary as the news makes it seem.

Post by ramanujan » Tue, Oct 26, 2010, 12:51 PM UTC

jfager wrote: post #207

ramanujan wrote: post #154

There are probably going to be a lot of people negatively affected by this for quite some time to come. One thing to point out is that there are grades of things. There is "public", and then there is "top hit on Google". Similarly, there is "insecure" and then there is "simple doubleclick tool to facilitate identity theft". How many millions of dollars and man hours is it going to take to lock down every access point…

Butler has not raised the threat level on anything. This has been a widely known issue since forever . A friend of mine wrote a sniffer that could do this back in college, and he was one of the last to the party. Want something else to kvetch about? His tool could impersonate the router and act as a proxy, including serving up ssl-encrypted pages to users who didn't realize they shouldn't accept certs from unknown si…