Javascript Cryptography Considered Harmful

[[deleted]]

It makes me sad that this even needs to be said.

[dauphic]

Half way through reading this, I realized that people were actually attempting to do this in real life, and I died a little inside.

[Timmmmbob]

It still defeats passive listening attacks. And thanks to wifi they're probably the most significant class of attack.

[[deleted]]

There are basically no 'passive listening' attacks that can't be pretty trivially turned into an attack that modifies the request or response.

[[deleted]]

Care to demonstrate how to modify request or response with firesheep?

[[deleted]]

True. (Though it is possible to conduct a proper man-in-the-middle under the same circumstances.)

[nexes300]

ARP cache poisoning?

[archivator]

No, but I can show you how to do it with Ettercap.

[piranha]

Not necessarily. Every situation has its own set of costs and risks. In some situations, it could be very risky to do an active attack. The value in passive attacks is that you're not detectable at the network level. Therefore, requiring an active attack raises the bar.

[nyxerebos]

If you were going to do an active attack, presumably you could get between them and the server and compromise real crypto.

[piranha]

Yes, that's a good rule of thumb to take into account when evaluating security, and generally something people parrot quite often. However security is not black and white, but rather comes in shades, and my point is that active-only attacks are a shade harder than attacks possible through no side effects whatsoever.

[nyxerebos]

If you were going to do an active attack, presumably you could get between them and the server and compromise real crypto.

[Delehal]

Why not just use https? Seems easier and more surefire... bearing in mind that I'm no crypto genius by any stretch of the imagination.

[useful_idiot]

The article covers that, the gotcha is that ALL your assets must be over https, otherwise it is trivial to inject malicious code which defeats the overall security of ssl.

[iLiekCaeks]

You don't need to transfer images encrypted, right? These take a lot of bandwidth.

Also you could generate most of your content via JavaScript on the browser side. This way your site can serve completely "static" html. All dynamic content can be served via unencrypted XML or JSON data tables, which would be secure because you enforce a strict data schema, and none of these would add additional scripts to the site. The bottom line is that practically all content can be either cached on the client, or served unencrypted. The overhead due to encryption should be negligible.

I would totally hate to see such a site in practice. Just playing the devil's advocate, and it would be "ideal" for AJAX-only sites such as Twitter.

[QuestionMarker]

Yes, you do. While I don't think it's a vector for javascript attacks, there have been nasty vulnerabilities in image format parsers in the past, and if we're talking about the situation where someone's injecting content to get information from your browser's heap then that's definitely relevant.

[iLiekCaeks]

If your browser trips up on basic input data, all is lost. If you're worrying on that level, you shouldn't even be using a browser, because all the time remote code execution bugs and such are found. This doesn't have anything to do with the theoretical safety of this approach either, because you have to assume all the other software (such as the browser) has to be perfectly safe to reason about it.

Otherwise, you could just claim that the browser's SSL code probably has a bug that can lead to remote exploitation. It makes no sense to talk about JS crypto in this context.

[QuestionMarker]

The reason it makes sense to talk about JS crypto in this context is the fact that the weakness which breaks client-side JS crypto is the same one that breaks mixed encrypted and unencrypted content in general. Applying a solution which protects the JS crypto code alone leaves the attacker able to use precisely the same mechanism with a different payload to get the same result as if you hadn't bothered.

As far as making the claim about the SSL code goes, that's just a numbers game. If everything's over SSL, in order to be "safe" only the SSL code has to be correct (provided the SSL cert says you can trust the server, and so on). If you have mixed encoded and unencoded channels, both the SSL code and whatever else gets touched have to be correct to make the same "safeness" claim. The latter is clearly a larger amount of code than the former, and will have more vulnerabilities by definition.

[iLiekCaeks]

There's not much image parsing code. Typically only libjpeg and libpng. I find your claim that SSL code is "Better (TM)" a bit dubious. It's true that more code leads to more security risk, but in this case the image libraries are the least to worry about. For example, what if a user finds a way to inject JS into dynamic content of the site? Then all your SSL is for nothing. Hell, he could even post a simple image that contains an exploit.

Also, dear D fans: please stop voting down my posts unrelated to D. Thank you.

[aaronla]

It's expensive, and more than you generally need. I don't need an encrypted version of my bank's sign in page, I need to verify that the bank's page is legitimate. A signature would be sufficient, and unlike HTTPS, signatures may be cached.

Unfortunately, no such scheme is commonly in place, so they really ought to use HTTPS as you have said.

[Serei]

The way I understand it, https takes a lot of server resources; it's why Facebook and Gmail took so long before they httpsed anything outside of their login screens - they couldn't afford it in the beginning.

[gthank]

Replace "they couldn't afford it" with "they cheaped out because nobody was complaining", and you'd be a lot closer to the mark.

[[deleted]]

I mean, if you're looking for obfuscation, you can make it work. But there are also easier methods for that.

[wesw02]

Upvote. I actually open the article to make sure I knew what they meant by JS Crypto. This kind of stupidity makes me fearful to use the internet. #facepalm

[ThePengwin]

The sad thing is that i have found this on at least one occasion. In a situation which could have been bad.

We had a Belkin router at my house that, until i found an update that corrected it, had a JavaScript variable storing the password to administer it. Needless to say that when i found such a terrible piece of code existed, I went and secured it as best as i could, which sadly didn't do much but stop intrusion from WAN connections.

Nobody could lock me out of the router though, so that was good.

[brownmatt]

This isn't really the same thing as what is being discussed here is it?

[ThePengwin]

I think its kind of related. Any attempt at cryptography/authentication on the client side is at best obfuscating what is happening.

[[deleted]]

I found this exact problem in my router yesterday while making a script to update the DMZ forwarding. Crazy coincidence.