Hey, does anyone else see the effects of bold text tag that didn’t get closed properly in kl’s comment? Or is it just me?
(I see it on latest firefox Ubuntu 10.10 and Windows XP, and I’m too lazy to inspect the html.)
Websites I’ve designed have used the technique Oskar describes to make a canonical string from data about the client, which is hashed to make a more individual session key. It works.
A hacker would need to fake a few details about a customer’s active session to steal it. It’s enough to not be the lowest hanging fruit.
HTTPS wouldn’t be too much of a pain, except for maybe upgrading to a NIC that has full TCP IP and SSL chimney offload to accelerate it, and some possible problems with mixed HTTP/HTTPS content on the same page (ads), and that’s probably the biggest barrier to wide-scale SSL adoption.
Luke
Let’s close this BOLD text first
Session ID’s are saved through cookies, so if your security is based on sessions, it is based on cookies.
IP is pretty secure, but since the ip would come from the router / provider and not the computer, this adds nothing to prevent something like firesheep.
Also, people who use AOL have dynamic IP’s, which can change at every request, breaking every site with IP-Based security.
User Agents are meh, it does add security, but not much.
Personaly I make sure that IF a session gets stolen, a person can’t do TOO much damage, highly personal data (like credit-data) is only shown partialy and nothing personal can be changed without a password.
TL:DR
A website can’t do much to prevent session theft so it is better to assume every session will be stolen and make sure nothing can go to hell if that happens.
“That cookie is always broadcast in plain text every single time you click a link on any website. Right out in the open where anyone – well, technically, anyone who happens to be on the same network as you and is in a position to view your network packets – can just grab it out of the ether and immediately impersonate you on any website you are a member of.”
(emphasis mine)
Very misleading. Jeff, i’m sure you understand how cookies really work, so i’ll assume this is just poorly worded, but for the benefit of others reading: a single cookie will only ever be sent to a single domain, at most, and cannot be used to impersonate your identity on other websites.
Hopefully that closes the bold. It does in the preview window.
@Jo and Kang Su G.
“It would seem this Firesheep would also work on wired connections within the same subnet. Is that not the case?”
It depends on the networking equipment. If it’s a hub, then yes. If it’s a switch or router, then no. Hubs fell out of favor years ago because Switches, for slightly more money, were considerably faster. Namely because a switch doesn’t broadcast every packet to every computer, only to ones with matching addresses… or to the network gateway/router, which is responsible for sending the packet on to the next part of the network, or in home-use cases, to the public Internet.
So does Yahoo mail simply not support HTTPS? I used Chrome + Use HTTPS (https://chrome.google.com/extensions/detail/kbkgnojednemejclpggpnhlhlhkmfidi) and when I logged in to mail.yahoo.com and provided credentials, I got this “The webpage at https://us.mc1103.mail.yahoo.com/mc/welcome?.gx=xxxxx might be temporarily down or it may have moved permanently to a new web address.”
What I’d be interested to know is how hardened the wired side of the typical coffee shop is. Encrypting the Wi-Fi traffic doesn’t help you against that.
@queisser: “how hardened the wired side of the typical coffee shop is.” Considering most shops are not run by computer security experts I’d wager that the router is probably right next to the stereo controls for when they have to reset it.
Technically, I guess you would have to trust the coffee shop manager to not put a box in between the router and their internet connection in order to capture the traffic. But we have that problem everywhere already.
All of this reminds me of when I was giving a talk to some co-workers on network security. I fired up cain and able and showed them half the company’s twitter, remote email, and facebook passwords within 5 minutes. The impact was everyone was a little bit frightened. BTW, the desktop machines were plugged into a router (not a switch/hub). The network guy had failed to do anything other than plug it in and it was defaulted to act like a basic hub (thanks Cisco). This was not a small company and they should have known better.
a single cookie will only ever be sent to a single domain, at most,
and cannot be used to impersonate your identity on other websites.
While that is technical true, most people don’t understand how serious the lack of SSL is:
If I’m in such an open wifi (without you using VPN), I just have to intercept ANY http page you access and on the fly add some img-Tags into the unencrypted, unprotected html you download. That way I can make your browser send me many more cookies!
And another big big problem: Did you notice how IE sometimes warns you that secure and insecure traffic is mixed? Mostly because of horrible ad netwoks?
The attacker just has to modify that js that is loaded insecurely into a secure page and insert some javascript to steal the cookies and send them to me using GET-requests!
ALWAYS use VPN!
You could protect yourself online when using public WiFi networks by tunnelling your HTTP traffic through server over SSH.
See http://thinkhole.org/wp/2006/05/10/howto-secure-firefox-and-im-with-putty/ for how to set it up using putty + firefox
Some websites won’t do HTTPS for all traffic since they rely on Google Adwords for sponsorship. However Adwords won’t allow HTTPS based advertisements.
Can someone convince Google to offer HTTPS? Otherwise they are encouraging bad paractices
What we really need is some way to encrypt just the cookie. I mean, seriously, I don’t need my images, my css, my js or even my html encrypted, just the login.
Before I get totally blasted off the internet, I suppose I should clarify that the the transmission of login/cookie needs to be encrypted, not just the cookie value itself. Encrypting the cookie value wouldn’t really help. Still, it would be nice to be able to separate that process from the transmission of regular data, which often has no need to be encrypted.
Now I’m quite ignorant about good http security but it seems to me that using different passwords for each website would help a little. Not much but at least only those websites that you visited from a given WiFi hotspot would be vulnerable.
I really like the open soruce KeePass utility as it will generate random passwords and I can use a hot key to fill in my userid and password.
One complaint though is websites that don’t allow a 20 character password and don’t ell you that it’s too long. So you register with a 20 character password which is truncated and now you have to figure out what the length really is.
Of course folks reading this blog undersrant this issue. The masses have not a clue.
Does this “trick” apply if the cookie pertains to an SSL/TLS session? In other words, if I access my bank account - is the cookie still in the clear - not encrypted by SSL?
@Mystagogue:
No, SSL/TLS negotiation happens before most HTTP headers, including Cookie. TLS has a possible exception for the domain name (Host?) header, but support for that is not mandatory… Apache web server, I’m looking at you!
Also, the cookie specification allows you to specify that cookies are only sent if it is a secured transmission.
@Jeffrey Davis - There’s a number of issues with that:
Lets look at a http get request (using Fiddler2).
| Yes, you can naively argue that every website should encrypt all their traffic all the time, but to me that’s a “boil the sea” solution.
The sea should be boiled, because guess what, HTTPS is your mystical “more secure identity protocol than ye olde HTTP cookies”
| I don’t actually care if anyone sees the rest of my public activity on Stack Overflow; it’s hardly a secret.
Nobody is worried about the publicly accessible information being read.
| Encrypting everything just to protect that one lousy cookie header seems like a whole lot of overkill to me.
I don’t want to be profiled in a database at my ISP or local neighborhood government cyber-spy agency of what websites I goto, what content I’ve read, or what my general habits are, that’s between me and the website. The comment I’ve posted here, my ISP knows that I’ve done that. I don’t have a problem with “Brian G. – Content” being on this public website, but I don’t want it to be hijacked along the way (from various nodes that carry the packet), nor do I want to get profiled.
Don’t forget about ARP spoof when connected to a switch/router, you can still intercept those packets if you arp poison.
Using SSL across an open network is simply not enough. Moxie Marlinspike has outlined a relatively easy way to hijack SSL sessions on an open network (http://www.thoughtcrime.org/software/sslstrip/) with his freely downloadable tool. Simply put: Don’t trust open networks.