Firesheep and secure access control with cookies.
- October 27th, 2010
- Posted in Uncategorized
- Write comment
For those that haven’t heard, there is a new firefox extension that simplifies what was once a complicated bit of hacking, is now so easy anyone can do it. It’s called firesheep. Basically it’s a combination of a packet sniffer with a built in cookie hijacking mechanism. It’s something that’s been known about for quite some time, but no ones bothered to fix because of the knowledge required and the difficulty in retrieving and implementing the hijacked cookies.
A simple, but costly, solution is that all providers just switch to using ssl for every request. This however has it’s own problems. Each ssl site must reside on a unique ip and port combination. However, since 443 is the standard for ssl ports, it means each site really has to have it’s own unique ip. That just wont happen for most sites. A lot of hosting providers actually use just one ip to host thousands of domains, and only give a site a unique ip when they require ssl.
Another solution is to use ssh proxing. This is what I do when I’m on an untrusted network. Not everyone can do this though, it requires a bit of knowledge and a secure server open to the internet where you have ssh access. Just to make it really easy to switch back and forth I wrote a bash script for the mac to do this for me. First I had to set up a new network location called “Untrusted” and enable socks proxing on port 8887. Below is the bash script.
#!/bin/bash
if [ "$1" = "-s" ]
then
if [ -f ~/.proxy.pid ]
then
echo "SSH Proxy Tunnel appears to be running!"
else
echo "SSH Proxy Tunnel appears to be off!"
fi
else
if [ -f ~/.proxy.pid ]
then
PROXYPID=`cat ~/.proxy.pid`
kill $PROXYPID
echo "Killed SSH Proxy Tunnel!: $PROXYPID"
echo `scselect "Automatic"`
rm ~/.proxy.pid
else
ssh -NCD 8887 user@host &
PROXYPID=$!
echo "$PROXYPID" > ~/.proxy.pid
echo `scselect "Untrusted"`
echo "SSH Proxy Tunnel Started!: $PROXYPID"
fi
fi
Just be sure to change your user and host in the file before saving.
I think that the only real solution would require a change to how browsers and servers work. For example:
Instead of encrypting the whole connection maybe just encrypt the information in the cookies. If the cookies don’t decrypt properly then clear the session. Yes people can still grab the encrypted cookie and send it along, so make it a time sensitive thing. When a user logs in they provide a username and password. Both the server and users browser could use this to create an encryption key. The browser and server would also exchange timestamps. Whenever a cookie is presented to the server it would also have to send an encrypted timestamp using the key that was created when logging in. The sever could then decrypt the timestamp and compare to it’s clock. If it differs by more than a set amount then the cookie is thrown out. This could cause some issues for people with really high latency connections, so maybe let the browser set the timeout at login. This way the user can choose how secure they want their connection allowing for those with high latency.
No comments yet.