Sidejack Prevention
github.com
github.com
Works perfectly on Facebook and Twitter without your session cookies every leaking (including the initial HTTP request) and including like buttons, etc.
Add any other site in options (Twitter and Facebook are on by default - I added github.com to mine and it works perfect, you may just need to re-login)
It seems like an important area of development for the web community to improve the tools and services available to make SSL on regular sites easier to implement. Yes, it's easy to turn on SSL, but there's a lot of nuance in a good implementation.
It's a shame that we can't go all SSL, but that's just the way it will have to be. The best we can do is make it difficult to hijack access to our tools that require elevated permissions.
The solution to FireSheep is something akin to SSL (robust, fast encryption with authentication). Could be SSL, or a VPN, or an SSH tunnel doing SOCKS.
Beware the MITM attack if you think all you need is encryption without authentication.
If you are specifically targeted, you're probably screwed no matter how good your security is. If the attack isn't getting through remotely, it may escalate into social engineering, or even into physical attack, up to and including physical keyboard bugs and monitor signal sniffing.
If you're not specifically targeted, and are merely part of the crowd, you don't have so much to worry about, because you can play the numbers game. All you need to be is more secure (a couple of standard deviations) than the average. In these circumstances, security through obscurity is statistically measurable: yes, in the binary sense it's wrong to think of obscurity giving you security, but in the practical sense, it measurably decreases your risk of being compromised.
Means that the client is not only authenticating the server, but the server is also authenticating the client.
Client cert interfaces in browsers are fairly user friendly, and github already has user keys, so they may as well make it an account option.
Since the concept is so ridiculously simple, I'm sure anyone can trivially implement it. The only issue is that it needs HTML5 Local Storage to work.
1. HTML rendered by the server has a small piece of code to generate an RSA Key Pair on the client using Javascript.
2. The randomly generated keypair is stored on the Client using the HTML5 Local storage mechanism.
3. For every request that the client sends the server, it sends the RSA Public key along with it. Also, the Server's Public Key is known by the client, and all outgoing data is encrypted.
Of course, this won't mean that the entire Website will be secure. It'll be quite trivial to create a small script to force all Form Data to get encrypted with the Server's public key - thus making sure that atleast your Passwords aren't transmitted in Plaintext.
In fact, with my current startup's application, the user's Password would never even _leave_ the client machine. Javascript would perform an MD5 hash, and the server treats that as the client's password. The issue with this is that you'll need JS active on all browsers for it to work.
Now sure, you could access the server one from a trusted connection to get the public key. But then when someone spoofs the public key you get a large and nasty error message saying the public key has changed. And history tells us that security can't safely be reduced to that type of user interface problem.
Long story short, you're massively underestimating how valuable it is that web browsers ship with certificates installed. When in doubt, don't re-implement SSL. ;)
Thank you for pointing out where I was wrong.
It's not just that the servers public key can be replaced on the victim's machine, but also an attacker can send their own public key instead of the victims to the server. During a MITM attack, all traffic would be fully viewable to an attacker without anyone really being the wiser.
1. That your HTML used to genereate the RSA Key Pair hasn't been intercepted and modified.
2. That sending the public key is equivalent to encrypting the document with the public key.
3. That there's nothing sensitive in the response.
4. That RSA crypto in Javascript is going to be quicker than SSL for either party (encryption client side, decryption server side).
There are other problems I can see but don't really have time to articulate.
Crypto is really, really hard. Fast crypto is harder. Secure, fast crypto is even harder still.
Security in general is really hard too. SSL is the way to go without user changes being required. some sort of crypto-tunnel (SSH, VPN, SSL) is the way to do it client side on an untrusted network.
I was just trying to jump on the "Look mommy! Look at what I can do with Javascript and HTML5" bandwagon :)
If an attacker is able to steal your session cookies there's a reliable chance that they're already on your network. Therefore, if they're already on the network, what's to stop an attacker from sending the server their own public key in lieu of the victims or sending the victim a fake server public key. Either way all the data passing between the victim and server would be viewable to an attacker. Also, the server's public key would have to be mutable so couldn't an attacker simply "correct" the victim at any point in the transaction all the while missing the initial handshake?
Edit: While I think that security around session cookies is important for websites to implement, there is a sharp line where it becomes too much. In this instance, given a perfect implementation of your idea with no legitimate potential for a MITM attack, then it would be far easier to simply strip the protection. Rather than trying to send fake keys around, simply remove the necessary things when the user is connecting to the page. (Think SSLStrip.)
In some respects it makes you wonder why browsers never had this natively in the first place - why should a third-party need to know my password when it could just send a hash instead?
So if I send MD5 ( Password + Salt String), even if the attacker sniffs this and logs on as the user, the original password string isn't compromised, despite the fact that the salt string is publicly visible.
<input type="password" name="secret" hash="yes" />If you use a vulnerable service, just write a Firesheep handler for it, publish it, and then let the provider of that service know.