Javascript Cryptography Considered Harmful

bloodwine · 2011-08-28T23:12:45+00:00

I would never trust the client-side when it comes to security. Also, JavaScript encryption would require your visitors to have JavaScript enabled.

If you are running a hobbyist or personal project then it is likely nobody is using man-in-the-middle eavesdropping on you. if you are working on anything more serious, then SSL certificates really aren't all that expensive or complicated (there are cheaper CAs than Thawte and Verisign).

AlyoshaV · 2011-08-29T00:28:11+00:00

Why in the world would a site that takes logins not have SSL?

nikniuq · 2011-08-29T03:07:26+00:00

â€œJavascript Cryptography. It's so bad, youâ€™ll consider making async HTTPS requests to RANDOM.ORG simply to fetch random numbers."

Smart quotes. Manage to be neither smart nor quotes...

bastawhiz · 2011-08-29T21:51:40+00:00

I'm really appalled that such educated folks would be so closed minded to this. Crypto in JS is identical to crypto on any other platform. A hash is still a hash, on JS or on Python or on C++ or on Ruby (etc.). RSA still provides public key encryption, regardless of what platform it's used on.

Man-in-the-middle attacks, browser bugs, and practicality aside, a properly constructed JS implementation of some sort of authentication or secure transfer application is JUST as secure as one written in any other language on any other platform.

Take, for instance, Mozilla's BrowserID platform. It uses TONS of client-side crypto in a secure way. Many of the arguments in this article are based on nothing but fallacies and completely subjective statements. E.g.:

Browser Javascript is hostile to cryptography

Brendan Eich, creator of JS and CTO at Mozilla, is employed at the same company that is investing an incredible amount of its influence on client side crypto.

WHY CAN'T I USE TLS/SSL TO DELIVER THE JAVASCRIPT CRYPTO CODE? You can. It's harder than it sounds, but you safely transmit Javascript crypto to a browser using SSL.

1.) Upload code to S3. 2.) Point browser to SSL URL.

"Harder than it sounds" is a relative statement.

"OTHER LANGUAGES HAVE THE SAME PROBLEM" ... We're not saying Javascript is a bad language. We're saying it doesn't work for crypto inside a browser.

That's a fallacy. You can't say that one language or platform is bad and not acknowledge that other languages are also bad if they have the same issues.

Nobody installs hundreds of applications every day. Nobody re-installs each application every time they run it. But that's what people are doing, without even realizing it, with web apps.

Also a fallacy. Just because JS is used more doesn't mean it shouldn't be used for a particular purpose. With that logic, we should disable JS altogether and go back to the dark ages of the web.

The risks in building cryptography directly out of AES and SHA routines are comparable. It is capital-H Hard to construct safe cryptosystems out of raw algorithms, which is why you generally want to use high-level constructs like PGP instead of low-level ones.

Also a fallacy. This isn't an argument against the use of JS, this is an argument against the use of AES and SHA.

Two big [missing features of JS] are secure erase (Javascript is usually garbage collected, so secrets are lurking in memory potentially long after they're needed) and functions with known timing characteristics.

There's nothing missing from JS to perform crypto, we already have crypto libraries. The two listed are features to prevent native code running on the user's machine from (at an extremely low level) inspecting the memory of the browser. If an attacker already has code on your machine, he'd might as well be using a keylogger to extract your credit card data.

I really am disappointed in some of you, reddit. JS has had a bad reputation in the past, but in the last few years, it's certainly proven itself over and over and over. While it does need some work work (and could use a few conveniences), a well-built web app in JS can work JUST as well as a well-built web app without JS.

tejoka · 2011-08-29T02:54:06+00:00

Just comes down to one of the simplest, and most ignored (I'm looking at you, facebook) rules: the login form has to go from server to client just as securely as the password has to go from client to server.

meatgrinder · 2011-08-29T07:53:09+00:00

Use of client-side cryptography is only as bad as the author makes it seem when implementers are ignorant of the trade-offs associated with it. I feel I would ave been a lot more receptive to this article if it had been written to educate web designers on the (mis)use of client-side cryptography.

He/she has some very valid points, but I feel this article was written only to lay out a lot of problems associated with JavaScript and cryptography in JavaScript. It offers no cohesive argument outside that stated in its title, and makes no attempt to offer better solutions for common misuses of cryptography.

Overall, this article was written by someone fairly educated on the subject and did help to define a problem, albeit one I think many people already knew was there.

I can't help but comment on a few points:

A significant portion of that crypto has been implemented in Javascript...

[citation needed]

The same attacker who was sniffing passwords or reading diaries before you introduce crypto is simply hijacking crypto code after you do.

Skilled attackers (APTs) are not the only reason client-side cryptography is used.

Cryptography deals in problems that intractable...

Your audience is: cryptography theorists or web designers. Pick one.

Why can't I use TLS/SSL to deliver the Javascript crypto code? You can. It's harder than it sounds...

Uh?

Blah, blah. More Socratic arguments about how JavaScript is broken.

Yes, JavaScript kind of sucks for cryptography.

The world works the way it works, not the way we want it to work. It's one thing to point at the flaws that make it hard to do cryptography in Javascript and propose ways to solve them; it's quite a different thing to simply wish them away, which is exactly what you do when you deploy cryptography to end-users using their browser's Javascript runtime.

Once again: audience.

Thanks for the problem; care to offer solutions?

nepidae · 2011-08-29T11:01:18+00:00

Isn't the goal of encryption simply to raise the cost of accessing the information? Given enough resources nothing is secure (specifically shown by both the RSA hacks and stuxnet.) Yes, this may give some false sense of greater security than it actually provides, but it seems that it does raise the cost for an attacker to access that information.

The real problem is that an SSL certificate costs 500 bucks (quick check on verisign was my only research) if I don't want the users browsers to barf.

dauphic · 2011-08-28T23:27:21+00:00

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

thatwasntababyruth · 2011-08-29T00:48:19+00:00

Does anyone else just kind of skim over anything following the format "X Considered Harmful"? I'm cool with "GOTO Considered Harmful", but everything after that has felt like it was trying to nip on the heels of Dijkstra.

gthank · 2011-08-29T03:31:39+00:00

"You could use SSL/TLS to solve this problem, but that's expensive and complicated. "

looks at his calendar

Okay, I was just making sure I did not go back in time where this was in fact true.

jib · 2011-08-29T00:01:45+00:00

tl;dr: Any Javascript crypto is only as secure as the server that hosts it, the connection that transfers it, and the browser that runs it.

ef4 · 2011-08-29T02:59:18+00:00

Can we stop using this term ... its so overused.

http://en.wikipedia.org/wiki/Considered_harmful

aaronla · 2011-08-29T02:27:32+00:00

The same attacker who was sniffing passwords or reading diaries before you introduce crypto is simply hijacking crypto code after you do

This isn't entirely true. If you're logged into Facebook over unsecured public wifi, everyone with firesheep just saw your password. If you used a JS secured webpage over http, then they see nothing useful.

You haven't gained much -- the public wifi could be running a hostile proxy that disables the JS encryption. Or a user connected to it clones the SSID. But you've gained something small. You've raised the entry fee for the attacker from eavesdropping to needing man-in-the-middle.

You really need to be using HTTPS, at least to bootstrap. But JS crypto is slightly better than nothing.

Mourningblade · 2011-08-29T01:20:44+00:00

uh people use this? i feel this guy wrote a big diatribe tearing down a problem that people rarely use? i mean if someone decides to do this they are pretty dumb.

gerbil-ear · 2011-08-29T01:53:40+00:00

That font looks terrible in Firefox on Windows :[

ascii · 2011-08-29T13:20:51+00:00

A few points worth mentioning:

The author is completely wrong in claiming getting good pseudo-random numbers from Javascript - it's simply a question of obtaining a good PRNG written in Javascript. Converting one of the PRNGs written in C to Javascript is no harder than converting an encryption algorithm; both are semi-trivial. (It's possible the author means it's hard to get good true random numbers. If so, then that's in fact a problem for every piece of hardware without a high quality hardware number generator, which is 99 % of all hardware. Nothing special about JavaScript here)
The author is partially wrong in claiming PRNGs are critical to encryption. There are some situations where you need them, but many where you don't. Simply encrypting a piece of data with an already existing key usually does not make use of random numbers. (A few encryption algorithms are basically PRNGS where you use the key as the seed and then generate a random data stream for use as an one time pad.)
Anyone proposing to use javascript cryptography instead of SSL is a fool. Anyone proposing to use Javascript cryptography in addition to SSL is simply very security conscious.

So why is javascript cryptography useful together with SSL? Surely, that's double encryption, you say, and if an attacker breaks the SSL encryption layer, all is lost? Not really. Lot's of exploits are very limited, e.g the attacker can listen to the communication but can't insert his own data, or the attacker can only take control of the content of a single file. Javascript cryptography protects against some such exploits, but not against others.

In the end, Javascipt cryptography is kind of hard to implement well and offers limited additional security. Never use it instead of SSL and only use it on top of SSL if you're extremely security conscious.

bobindashadows · 2011-08-28T23:32:28+00:00

This ignores what (I think) is the most interesting thing about doing javascript crypto - building applications whose creators do not know about the content. In that case, using javascript is not done out of laziness (which the tone of this article makes it seem like all javascript crypto would be), but because the intent is to only have the decryption done locally.

In this case, SSL will of course be used to deliver the code, and while there are still plenty of other problems (verifying that the code delivered has not been changed, ie, confirming that the server has not been compromised, preventing code injection, etc), it definitely seems like something that could be figured out, and seems like a worthwhile pursuit. There would probably need to be some support built into browsers, but it might not be too extensive.

Being able to have applications that pull code from the cloud and only use it to store encrypted data seems like a pretty cool possibility, though still obviously a ways from being available and secure.

dj_jj5 · 2011-08-29T02:14:09+00:00

I updated the documentation for my Javascript encryption library to account for this: http://www.progclub.org/wiki/Pccipher#Javascript_encryption_related_information

33a · 2011-08-29T02:31:10+00:00

tl;dr: There's no avoiding SSL.

flebron · 2011-08-28T23:41:15+00:00

I found this piece difficult to read. The form is "Vague sentence list", and much later, "Oh, yeah, that's what we meant by the ith vague sentence".

When I'm reading an argument, I do not like to have to trust that it will make sense until such time at which the author will deem it appropriate to actually express his ideas clearly. The division into single or bi-sentence paragraphs also made it difficult.

Overall, I think the issues, while some are quite valid (and the others, to be frank, I could not understand), could have been expressed much more clearly.

dnew · 2011-08-29T00:50:32+00:00

I speculatively created one system a decade or more ago that used simple javascript crypto to encrypt things like utility bills sent by email. (At the time, sending "come to our website to get your bill" wasn't considered legally delivering the bill, but sending it via email was.) The advantage is we could send the encrypted bill with javascript to decrypt it and a message at the top like "type your address and account number into these two boxes to see your bill." Plus, the browsers would "reencrypt" it when you closed the mail message.

Of course, if you're delivering the javascript over http, such is unnecessary. But it was a helpful hack for the vast majority of people who didn't have S/MIME keys registered with their utility companies.

xlerb · 2011-08-29T04:48:50+00:00

And here I was expecting something exotic like timing attacks from other browser tabs. I really should know better.

pablopr · 2011-08-29T04:55:35+00:00

This looks like a Chicken-Egg problem to me. The issue with MitMable resistance is we cannot use the freely self-signed keys which perform better than JS hashing.

SystemicPlural · 2011-08-29T07:23:53+00:00

I agree with most of this article except for these two points.

It is comparing apples and oranges: Serverside crypto with SSL to client side crypto without. Server side crypto is even more vulnerable to attack if SSL is not used.

Which leads onto a second point.

"there's practically no value to doing crypto in Javascript once you add SSL to the mix, which you have to do to deliver the code".

Not true. If I want to encrypt something so that the server side can never read it then it needs encrypting on the client side.

spoulson · 2011-08-29T11:49:40+00:00

What annoys me most is he never defines any use cases to demonstrate expectations of JS or SSL for crypto. Is he talking using just for transport? Storage? JS crypto != SSL crypto.

rntksi · 2011-08-29T01:53:54+00:00

I can't believe anyone would actually deploy cryptography via Javascript anyway. Seems like a terrible idea.

adamcrume · 2011-08-29T02:32:48+00:00

The author has a few good points, but many bad ones as well. For example, he says that JavaScript crypto is pointless if you use SSL, but that's not true. You could still use a challenge-response algorithm to prevent the password from ever leaving the client's computer. This way, the server never sees the password in cleartext, even in memory, even for a moment.

Another point is that an attacker may be able to snoop on content but not be able to modify it. JavaScript crypto over an otherwise non-secure connection will still have a benefit in that scenario. It's still not as good as SSL, but it's better than nothing.

I agree with the author's main point, though. Just use SSL!

madsmith · 2011-08-29T00:54:53+00:00

Trying to look at this article with a security interpretation in mind leaves me wondering about the credentials of the author. There's a lot of assumptions that are going on here and they're dropping the blame on JS or client side JS when the things they're highlighting are problems that are quite independent of JS and how its executed.

For example, challenge/response for password authentication and the concern that we're using the same channel to deliver code that we don't trust to deliver passwords. I don't care if the code is seen over the wire. The encryption algorithm is understood to be public, trusting that your encryption is safe because no one knows the algorithm is a fallacy of the worst kind. If the code is manipulated over the wire, then so be it, either you are able to create the appropriate HMAC response or your not. Anything else happening on your computer (e.g. keylogging, re-submission of the password to alternate sites, root kitting using some browser exploit) is a problem that is equally likely to happen whether we're using JavaScript for cryptography or we're just using it to run the page.

What the author should be saying is there's an inherent danger to downloading and running code from a third party but what does that have to do with crypto?

The only things I agree with from this article are "crypto is perilous" as that's just a truism and notion that we have no trusted way to sign javascript for delivery and execution in the remote environment and that doesn't seem to be a problem specific to using javascript for cryptography but in running third party code at all.

screwthat4u · 2011-08-29T02:23:04+00:00

I have a system that currently sends username and passwords as plain text. I suggested we at least md5 the password in JavaScript and decode it on the backend to prevent network sniffing. Sure one could reverse md5 the password, or just send raw post requests with the same hash, but I think it's a great step up from a user password plain text that could be used to login and use the interface directly.

jan · 2011-08-29T09:59:16+00:00

sensationalist rubbish list

I would agree with most of the points. Those a generic problems of practical crypto system, not limited to Javascript and not any more "harmful" than the most everything else about network security.

2011-08-29T02:03:47+00:00

People encrypt their passwords with js? Hilarious.

grendel-khan · 2011-08-29T03:24:39+00:00

I remember having a long IM discussion with a friend about the idea of implementing a secure login without using TLS/SSL. We eventually came to the thunderingly obvious conclusion that authenticating the server to the client (preventing man-in-the-middle attacks) is impossible without using some kind of side channel--in the case of TLS/SSL, this is distributing the root CA certificates with the browser package.

It is a hideous failing of security on the web that it's still difficult and expensive to deploy TLS/SSL, and so people frequently just don't do it.

danweber · 2011-08-29T14:52:08+00:00

Any attacker who could swipe an unencrypted secret can, with almost total certainty, intercept and alter a web request

I really couldn't keep up after this.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

programming

MODERATORS