Javascript Cryptography Considered Harmful

http://www.matasano.com/articles/javascript-cryptography/

by adgar • 15 years ago

207 174 15 years ago

glenjamin• 15 years ago

I don't see how implementing (correctly) an already known one-way hashing function (SHA/MD5 for example), and then using this to form part of a basic challenge-handshake protocol is not better than sending the password over the wire.

In this way the attacker would be unable to gain anything useful from seeing the challenge or handshake packets, and the only remaining vector is some form of keylogger.

Or am I missing something here?

jtdowney• 15 years ago

Under the heading That attack sounds complicated! Surely, you're better off with crypto than without it?

"Any attacker who could swipe an unencrypted secret can, with almost total certainty, intercept and alter a web request. Intercepting requests does not require advanced computer science. Once an attacker controls the web requests, the work needed to fatally wound crypto code is trivial: the attacker need only inject another <SCRIPT> tag to steal secrets before they're encrypted."

hollerith• 15 years ago

Also, grandparent assumes the choices are JS crypto and sending passwords in the clear, ignoring the SSL/TLS option.

adgar6• 15 years ago

> Or am I missing something here?

You're missing the real solution: SSL/TLS.

DarkShikari• 15 years ago

Timing attacks and other side-channel vulnerabilities.

tptacek27• 15 years ago

You don't have to anything that sophisticated; you can just intercept one of the HTTP requests that builds the page and insert code to steal the passwords.

wglb• 15 years ago

Under the "Really? Why?" section, start with the first point:

If you don't trust the network to deliver a password, or, worse, don't trust the server not to keep user secrets, you can't trust them to deliver security code. The same attacker who was sniffing passwords or reading diaries before you introduce crypto is simply hijacking crypto code after you do.

amalcon6• 15 years ago

Challenge-response hashing in JS is MitMable and likely to have implementation errors.

SSL has defenses against MitM attacks, and is implemented in very widely-deployed libraries, so if there's an implementation error you'll hear about it before it's used on you.

The drawback is of course that you need to have a signed key. That is the price you pay for MitM resistance. We're not supposed to use self-signed keys (which are free), even though they are strictly better than JS challenge/response hashing.

yuhong2• 15 years ago

Huh? If the session is MitMed, the plaintext password can be revealed, since encryption is not one-way.

hammerdr• 15 years ago

From the article:

This is strictly true from the perspective of cryptography. Crypto is always concerned with the strength of crypto from a mathematics point of view.

However, much of that worldview falls down in the real world. In the case of hashing a password before it goes over the wire (even the simplest salt-free MD5), which is crypto-logically naive and "considered harmful," you are providing a general barrier for people that are FireSheeping in a cafe. Many would-be attackers are thwarted by what crypto-nerds would see as silly.

In general, the weakest point of crypto in today's world is the human element. RSA Security got hacked not because the algorithm was weak but because someone installed a back door in RSA's network for the hackers. Once you get passed the point where it is more effective to attack sideways than head-on, the crypto has done all it can do.

That being said.. just use SSL. It moves that gauge enough that anyone trying to get your users' information isn't going to bother direct attacks.

Edit:

What I meant by the 'salt-free' MD5 is that of a challenge-handshake response. The challenge is sent by the server and the client responds with md5(pw+challenge). The salt would otherwise need to be sent in an insecure manner that would provide only marginal more security than a challenge-handshake. This was unclear and I apologize.

dchest• 15 years ago

What barrier? If you're sending password hash over the wire, and the server allows access based on this hash, the hash is essentially the password. Firesheep, BTW, steals cookies, not passwords.

benregenspan2• 15 years ago

"There are three misconceptions embedded in that common objection, all of them grave."

I completely agree with this article, but why do so many security researchers try to write like cartoon samurai?

thesteamboat• 15 years ago

Probably because it's fun? If you spend half your day reading papers on fully homomorphic encryption, I think we can forgive a little levity to compensate.

tptacek27• 15 years ago

I don't think it reads like "a cartoon samurai" (but then I don't know how samurai sound). What you're really noticing is how lazily written it is. That whole article is a single draft I wrote almost a year ago and never touched again.

You're seeing it because I was too hung over this morning to repeat all the arguments it contained when Javascript crypto came up on HN.

I didn't submit the article as a story; in fact, I've been sort of dreading it being submitted ever since I wrote the comment that had the link in it.

adgar6• 15 years ago

Actually, I submitted it because I saw it on Reddit, liked it, and was surprised to see it wasn't submitted here. Though somebody may have submitted it to Reddit after seeing your link on HN.

sneak• 15 years ago

Don't dread, it is clear and factual and free from obvious typos. You've even got a jwz quote and radioactive boy scout references - I rather enjoyed it.

benregenspan2• 15 years ago

Sorry for being an asshole - it's actually quite readable and gets the point across, I just meant to comment on the somewhat dire tone. Says something good about your writing if a quick draft gets the point across and people want to read it.

antimatter15• 15 years ago

It's easier for an attacker to passively observe a stream than to actively inject specifically tailored code into it.

At least with JS Crypto, amateurs with Wireshark and Firesheep probably can't steal your stuff. But since that's all the protection it offers, it shouldn't be advertised as anything more ("This NOTEr 2.0 App uses AES-256 in JS over HTTP to provide NSA GRADE security and privacy!"). In that sense, it probably causes harm to use JS crypto, but JS crypt isn't absolutely ineffective.

amalcon6• 15 years ago

It's only a little easier. There are three scenarios I've been able to come up with:

The attacker triggers some kind of bug or odd mode in a router. That router happily floods packets to the wrong places, but still only accepts them from the right place.

The attacker can decrypt your WiFi plaintext, but not in realtime. You've already received the response from the server by the time the attacker can craft one for you.

The attacker is afraid of getting caught (he possibly needs to be on-location, and can't work through an intermediary), and is therefore restricted to passive methods.

As it happens, all three of these are pretty unlikely. They aren't impossible, but why put forth a large effort for JS crypto when you could put forth a small effort for SSL?

marshray21• 15 years ago

Here are some ways to modify traffic on typical networks, most have command-line or GUI point-and-click attack tools available. Some of these are documented to have been conducted on wide blocks of internet traffic.

The attacker broadcasts a SSID of 'Free Public Wifi', or one similar to what you normally use, then DoSes all other access points when you try to use them.

The attacker is on the same ethernet broadcast domain and replies to your DHCP query quicker than the legitimate DHCP server does.

The attacker poisons the router's ARP cache and impersonates your MAC.

The attacker leverages the unauthenticated nature of Spanning Tree Protocol STP.

The attacker pwns your home wifi router through a default password on its admin page or any number of other bugs.

The attacker messes with your DNS name resolution for sites of interest. Remember that time DNS resolution for some S. American (and a few US) ISPs got routed through the great firewall of China?

The attacker advertises a more-specific route for your IP address or that of a target site. Remember when that little ISP in Pakistan took YouTube offline?

The attacker could be your ISP working under order of some government. Yours, that of a country you're visiting, or of some territory the packets pass through along the way.

Or you could be using a hotel, airplane, library, mobile, etc. internet connection where transparent intercepting MitM proxies are standard fare. How good do you think the hotel staff are at securing that internet billing appliance they bought?

And of course, the attacker could always cut a cable somewhere and install a tap.

tptacek27• 15 years ago

No, it isn't. It's actually harder. To intercept a stream, you need only capture a few packets. To passively observe it, you have to position yourself in a place that sees all the packets.

storborg3• 15 years ago

You're talking about computational difficulty. He's talking about practicality for people who aren't experts. AFAIK there is no browser plugin that you can download that will help you MITM an HTTP session, whereas there is a browser plugin that will let you passively capture plaintext from said session.

crdoconnor2• 15 years ago

>At least with JS Crypto, amateurs with Wireshark and Firesheep probably can't steal your stuff.

They can't with SSL either.

LiveTheDream• 15 years ago

I found this quote as telling as it is hilarious:

> Just as all programs evolve towards a point where they can read email, and all languages contain a poorly-specified and buggy implementation of Lisp, most crypto code is at heart an inferior version of PGP.

amalcon6• 15 years ago

I mostly agree with the gist, but it's not really the Javascript that's the problem. It's trying to do crypto in code downloaded over the network. Implementing crypto in a Flash/Java/Flex/Silverlight/other flavor-of-the-month applet has all the exact same problems. Well, you might have a secure RNG (doubtful), but apart from that the problems are all the same.

Likewise, it's probably possible (though very difficult, and still not a good idea) to have good crypto in JavaScript as long as it's either server-side or built into the client.

tptacek27• 15 years ago

Java crypto doesn't have all the same problems; the Java plugin environment has enough code to run crypto inside of it, and Java applets are (or can easily be) self-contained enough to verify integrity. Browser Javascript (and by extension Flash) is a uniquely hard place to make crypto work.

marshray21• 15 years ago

What are the circumstances under which a browser will refuse to run an unsigned Java applet in place of the legitimate signed one?

amalcon6• 15 years ago

If by "has enough code to run crypto inside of it", you mean "the SSL support and the javax.crypto library", sure, it gives you some useful stuff. You can also access all that stuff from JS without ever writing a line of Java code, so that's a wash.

As far as self-contained Java applets go, every attack that can be used against JS can be used against Java. It's a trivial exercise to instrument any method call you like, including calls to any method that attempts any kind of verification. Java bytecode is really quite transparent.

magikarp17• 15 years ago

It is ridiculous that even in light of the COMODO HTTPS hack, the writer would go as far as to say that SSL/TLS is a better solution.

The writer also ignores that there are potential solutions to many of the problems pointed out: In case of random number generation, check out seedrandom: http://davidbau.com/archives/2010/01/30/random_seeds_coded_h... And while it's true that the server may always send "poisoned" JavaScript code, projects that heavily depend on such code, such as Cryptocat, now ship browser plugins that perform integrity checks on the code for you: https://chrome.google.com/webstore/detail/dlafegoljmjdfmhgoe...

Furthermore, and most importantly, by using SSL/TLS, the data being sent by the browser to the server is encrypted as it passes through the network, but however remains readable by the server when it reaches it. Whereas with client-side JS crypto, the server cannot read the sensitive data. If the writer does not trust the server to send correct JS code, how can he trust it with the sensitive data itself, in plaintext, which is what he is doing by using SSL/TLS? As I mentioned above, there exist browser plugins for a few projects to verify the integrity of the JS crypto they use.

adgar6• 15 years ago

SSL/TLS is a better solution. I find it ridiculous you suggest that browser-based JS is better, frankly. Comodo was breached and the certificates were revoked using the theoretically-sound, tested, and implemented PKI solution. While you do well to point to existing attempts to work around JavaScript's deficiencies, it's genuinely surprising you could say they exceed the capabilities of SSL/TLS.

magikarp17• 15 years ago

What about sslstrip? What about the fact that CAs are being hacked left and right, and that governments such as China are known to produce fake certs to wiretap dissidents? What about the fact that the server can still read your data? Again, how can you trust the server with your plaintext if you can't trust it to serve you good JS crypto code? There have been attempts to mitigate this problem in JS crypto anyway, using browser plugins that perform integrity checks.

lawnchair_larry2• 15 years ago

SSL/TLS doesn't solve this problem noted by GP:

Furthermore, and most importantly, by using SSL/TLS, the data being sent by the browser to the server is encrypted as it passes through the network, but however remains readable by the server when it reaches it. Whereas with client-side JS crypto, the server cannot read the sensitive data.

This is a shortcoming in the argument made in the article, because it wrongly assumes that we would always want the server to decrypt our data.

I am not saying JS does solve this, but SSL doesn't, and it isn't even meant for that use case.

marshray21• 15 years ago

SSL/TLS is a better solution.

Absolutely, to the point that it's ridiculous to compare it to client-side Javascript.

Comodo was breached and the certificates were revoked using the theoretically-sound, tested, and implemented PKI solution.

Weeeellll actually... Mozilla, Google, MS had to rush out a code patch to manually blacklist the fraudulent certs. Revocation checking is implemented so weakly in browsers and other HTTPS clients that it just doesn't work when it comes down to it.

Of course, the browser Javascript doesn't have any problems of weak revocation checking. It's simply altogether unauthenticated in the first place!

tptacek27• 15 years ago

A user looking at the "cryptocat session verifier plugin" has to think to herself, "What is this thing verifying? Is it just checking a digest of the Javascript files? How does it know if the CSS files have surreptitious Javascript in them that negates the crypto?"

Which is funny, because if cryptocat just required a browser extension that implemented all the crypto, it wouldn't need to verify anything at all. What was the point of Javascript crypto at all, if you're just going to push an extension onto people?

Your unease with SSL/TLS and its X509 PKI is entirely orthogonal to whether Javascript crypto works or does not work. Wanting an alternative to TLS does not give you an alternative to TLS.

It's funny how many arguments supporting Javascript crypto devolve to "but the world would be so much better if this stuff worked".

magikarp17• 15 years ago

Actually, in the case of that particular plugin, every bit of code, including CSS, JS, and HTML, are verified.

> It's funny how many arguments supporting Javascript crypto devolve to "but the world would be so much better if this stuff worked".

It's hilarious how you completely ignore the much more pressing issues in HTTPS that I've pointed out. The server can read plaintext in the case of HTTPS, which is mitigated in JS crypto; not to mention that things such as SSLStrip and the COMODO hack have put many chinks in HTTPS's armour - HTTPS is a technology that derives a lot of trust from being able to authenticate the server, whereas we've seen authorities such as China create entirely passable fake certs to fool dissidents.

shazow• 15 years ago

The vulnerability of implementing crypto with in-browser JavaScript seems to be coming up more and more in the past year.

Tl;dr: A MITM could serve you a fake implementation of said crypto and you could very well be encrypting your content with ROT13 while thinking you're getting some NSA-grade security or what have you.

My initial instinct is "browsers should expose some native crypto functions which have always-preceding namespace priority" but after thinking about it more, it doesn't matter. The attacker could just push code that leaks data before it even hits the crypto functions.

Looks like the only workaround is to use SSL/TLS.

(This is all assuming that the implementation of the crypto is solid, of course.)

dublinclontarf• 15 years ago

Unless the JS is served over ssl/tls then it is vulnerable to a MITM modifying the code en-route.

Throw in ssl and that fixes that problem.

An interesting example of this is glbse.com, it's a bitcoin stock exchange, on the site there is a client python library and a JavaScript client application (to run in the browser).

Putting aside how poorly documented (and designed) the JS client is, what they use it for is authentication/authorisation not... for actually encrypting.

All requests from the JS client are signed with a RSA private key, the server keeps a copy of the public key, and verifies any incoming requests.

The private keys can be stored in html5 local storage (encrypted if you want).

The keypairs are initially generated on the server.

When they first started making this available it was being served over plain text http, now they use SSL for the reasons above.

The idea is to remove the need for servers to store username/password combinations. The users account ID is a sha256 hash of their public key.

https://glbse.com and the JS client https://glbse.com/client/glbse/ as I'd said the UI on this is terrible, but it's something they're working on.

fadzlan4• 15 years ago

That said, as other commenter has mentioned, should the server be compromised, the JS crypto lib may be overwritten with something else that steals the decrypted content in the browser.

The thing is, the browser still depends on the server for the crypto implementation EVERYTIME the user logs in to use the application.

Native application also suffers from this, since any downloads of the native apps still depends on the hosting server not being compromised. However, the vulnerability only applicable when the application is being download, instead of over and over again in each time of usage as in the case of web application.

The only way I can think of is of using extensions. In this manner the trust issue happen once during the download of said extension. By doing this, the implementation would be almost as secure as native application.

Almost as secure, because web pages are still content+execution. For the solution to be secure, the pages needs to be secure itself, since other Javascripts or the implementation of the web app could may not protect the user from XSS based attack.(You could say the same about native apps though, as the security depends on how secure is the codes against things like buffer overflow).

I personally thinks that it would be the best bet right now.

rdl• 15 years ago

That's a problem with serving java applets which do crypto, too. (there were some better protections for applets, but they're still vulnerable to code replacement by the server (thus not able to do hostproofing))

crdoconnor2• 15 years ago

While largely true, there is still scope for client side javascript encryption for applications where the service provider largely just wants to prove to some external agency (e.g. the government, or some court issuing a subpoena) that they can't have access to your data.

marshray21• 15 years ago

That'd be a hard thing to prove considering the service provider (and every other party serving non-image content into the page origin) could access the data any time they wanted by simply sending some script.

michaelchisari4• 15 years ago

Which is why encryption should be something that the browser handles internally. This is something I proposed recently:

http://wiki.appleseedproject.org/doku.php?id=future:encrypti...

(Note, originally in this proposal, I support the idea of using a browser plugin, although now I think it should be functionality baked directly into the browser)

By adding an encryption="" attribute to the html markup, and the user instructing the browser on how to utilize a private key on their system, you can encrypt and decrypt data in the browser, without requiring a trusted server.

starwed2• 15 years ago

Something like that seems horribly hard to get right.

Forget about cross domain scripting attacks, now you can't trust JS from the point of origin. Yet at the same time, you'll probably want it to be able to do all sorts of fancy AJAX-y stuff on the decrypted content. (Certainly on other parts of the page.)

michaelchisari4• 15 years ago

You're right, in order to get the security right, you wouldn't be able to access the decrypted content with javascript. The browser would prevent that from happening.

Yes, potential functionality would be lost, but that's always part of the trade-off for security.

But I don't think the trade-offs would be detrimental, from a usability standpoint.

thristian• 15 years ago

I haven't read your proposal, but your description sounds a bit like this: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/La...

michaelchisari4• 15 years ago

Interesting, I wonder when that proposal first went up (mine was first posted to lists in February). Could be a case of synchronicity.

tzs2• 15 years ago

Minor quibble:

   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. The
   problem is, having established a secure channel with SSL,
   you no longer need Javascript cryptography; you have "real"
   cryptography. Meanwhile, the Javascript crypto code is still
   imperiled by other browser problems

My minor quibble is that there are other reasons one might want cryptography besides establishing a secure channel, and so using SSL does not necessarily solve whatever problem one was trying to solve with JavaScript.

For instance, the client might need data that is stored encrypted on the server, and you want to do the decryption on the client.

tptacek27• 15 years ago

I think the fourth of fifth graf of this (poorly written, I agree) article explicitly calls out that there are reasons beyond a secure channel why you might want clientside browser crypto.

So, I'm actually going a step past the obvious argument against jscrypto ("this is an inferior way to build a secure channel"). Not only is it an inferior secure channel, but it's also an inferior and dangerous place to try to build crypto functionality even if you're using SSL/TLS to establish a secure channel.

tedjdziuba• 15 years ago

Put bylines on your articles. You are not The Economist.

morsch• 15 years ago

Exactly. I always considered JS Crypto orthogonal to TLS. You still want TLS for authentication and establishing a secure channel to ensure you're getting the right code from a person you trust.

Javascript (or generally, client-side) crypto would still be invaluable for other things. If it can be implemented safely, you could do stuff like GPG for mails and OTR for instant messaging. For Javascript, that appears to be a pretty big "if", though. If it can't be implemented safely, well, then it's a matter of opinion. Some will argue the crypto is still useful despite a couple of viable attack scenarios, others will argue that an appearance of securiy is much worse than no security at all.

dfox• 15 years ago

There is one (and probably only one) case when js crypto makes sense. And that is when server operator wants to convince third party that he cannot access encrypted data at rest stored on the server. Client side JS based encryption (and by the way also things like hushmail) does not help in any way when you don't trust the server.

jimktrains2• 15 years ago

> And that is when server operator wants to convince third party that he cannot access encrypted data at rest stored on the server.

Or the server actually doesn't want to store unencrypted data.

narag• 15 years ago

...server operator wants to convince third party that he cannot access encrypted data at rest stored on the server

Indeed. Or simply because the same party owns the server and the client.

jwatte• 15 years ago

I think using TLS is largely the right solution, and "shouldn't be hard" (a $400 certificate is the hardest bit). However, the article assumes that modify attacks are as simple as intercepted, which I do not believe is true. It's not about GUIs. Re-routing DNS requires holes and access that a properly configured infrastructure won't give you. However, as long as you can put up a competing DHCP server at an open Starbucks network, you can probably own anything non-TLS.

mcantelon• 15 years ago

"___ Considered Harmful" considered harmful.

swah• 15 years ago

Would be cool if this had an author listed.

tptacek27• 15 years ago

Hi.

donpark7• 15 years ago

While I agree with most of the issues raised in the article, I disagree with the blanket conclusion. With HTTPS, JS crypto can add to security when applied appropriately.

In particular, requiring hacker to compromise not only the server but also each client adds to security and limits damage footprint, much more so if combined with external blackbox-style monitoring of served contents and scripts to catch server-side compromise timely.

marshray21• 15 years ago

The clients don't need to be hacked, they simply run code as instructed by the server using standard, documented interfaces. Once the server is compromised, or any other party that can serve non-image content into the page origin, it's game over.

donpark7• 15 years ago

I didn't mean client has to be hacked but did mean script from compromised server has to run on client to decrypt user data. Hacker has to compromise the server then, for each connecting user, serve malware javascript.

Meanwhile, external network of monitors, masquerading as real users, detect that server is compromised and alert the admins who can take appropriate actions. Overall, compromised server can be shut down in minutes during which only a fraction of user base will have been affected.

How does this not add to security?

donpark7• 15 years ago

Also, I think it's inappropriate to downvote a comment thread before misunderstandings can be sorted out.

I've spent 10 years in the security industry building new technologies, several of which are used widely in large banks and payment services.

Nobody should expect respect but disrespect should not be so readily served IMO.

thinner• 15 years ago

FTA:"THAT ATTACK SOUNDS COMPLICATED! SURELY, YOU'RE BETTER OFF WITH CRYPTO THAN WITHOUT IT? There are three misconceptions embedded in that common objection, all of them grave..."

I guess I shouldn't lock my car, either, right? After all, someone could simply break my windows and steal whatever I have inside. Or maybe, just maybe, using some protection actually is better than using no protection, provided you don't put more faith in the protection than the protection warrants. Just like I wouldn't store gold bars in my car, I wouldn't use jscrypto to protect things that were too important for that level of protection. I will, however, feel okay about keeping my sunglasses in my car, and I will feel okay about using jscrypto to send my phone number over email.

marshray21• 15 years ago

I'm glad you mentioned this because I feel it's worth a response.

When you develop protocol or infrastructure code the more general the facility is that you develop the less control you have over how the result is going to be used.

For example SSL was originally developed for the purpose of making people feel safe transmitting their credit card numbers to e-commerce websites. Credit cards (like cars) have a pretty predictable upper bound on the financial loss should this system break.

However, the SSL/TLS protocol was very general and it has grown to be used for everything under the sun today. From protecting Twitter APIs to "launch the missiles"-type critical systems.

So when you advocate a general technique like Javascript browser crypto, you don't get to qualify it with "only for stuff that really isn't worth attacking anyway". You don't know in advance what data it's going to be used for, much less what the value of that data will be to attackers in the future.

tzs2• 15 years ago

So are there situations where it is reasonable to do JavaScript cryptography?

Here's a hypothetical: you have producers and consumers of certain documents. You want a system where a producer can produce a document for a particular consumer, put it on a server, and that consumer (and only that consumer) can retrieve the document and read it. Ideally, you want to this as unobtrusively as possible from the point of view of the consumer. If the server is compromised, the intruder should not be able to read any of the documents. It's hypothetical, but something I once worked one would have benefited from such a system, so I spent some time considering how it could be designed.

One approach would be to have a public/private key pair for each consumer. When a producer prepares a document for the user, it is uploaded encrypted using that consumer's public key. The encryption would be done on the producer's client machines (producers are on a company LAN using computers administered by a competent IT department, and can be assumed free of malware).

On the consumer side, we need to solve three problems: (1) generation of the public/private key, (2) storage of the private key, (3) decrypting downloaded documents.

One approach to this would be to tell the clients to install PGP, generate keys, and send the public key to the producers. Clients could then download documents via their browser, and run PGP to decrypt them. That fails the "unobtrusive to the client" requirement.

So let's consider the JavaScript approach. The JavaScript can be delivered over SSL, with all elements of the page coming over SSL from the same server (which could be separate from the document storage server).

For generation of the public/private key, the lack of a secure random number generator in JavaScript would seem a hindrance, but is it? Couldn't a CSPRNG be used in JavaScript, seeded with something derived from the user's password? That would have entropy limited by the entropy in the user's password--but how is that different from using a secure random number generator but then storing the private key encrypted with the password? In either case the difficulty of getting the private key for an attacker is limited by the entropy of the password.

If the private key is generated as above, it can be regenerated from the password as needed so there is no need for key storage.

It seems to me that the above sidesteps most of the issues raised in the article that are specific to JavaScript. The ones that remain, where someone has compromised the client machine via another route, would also apply to a client implementation done as a stand-alone application. If the client machine is compromised, the client's documents are vulnerable.

Let me also propose one more scenario. What about JavaScript that is NOT delivered over the net on each use? For example, suppose (still using the hypothetical producer/consumer example) that when a consumer signs up for the service, the sign up server generated the public/private keys, then dynamically created a static page with embedded JavaScript that includes the private key (encrypted with the consumer's password) as data. This static page is bundled up with any other resources it needs (images, style sheets) into a zip file, and that is given to the client.

The client unzips this, and when he wants to get documents launches the static page in his browser. The static page references its resources by file:// URLs. Essentially it is an application that happens to use the browser as an execution environment. The network is only used to make an AJAX call to get encrypted documents from the server.

saurik• 15 years ago

""That would have entropy limited by the entropy in the user's password--but how is that different from using a secure random number generator but then storing the private key encrypted with the password? In either case the difficulty of getting the private key for an attacker is limited by the entropy of the password.""

Because you just removed the requirement of the attacker to steal (or at least compromise) the laptop, to get access to the encrypted key: the entropy of the key was still high, it was simply protected on the laptop with a weak password; that's very different from deleting the key and forcibly reducing its entropy to that of the password.

rmc3• 15 years ago

If the server is compromised, the intruder should not be able to read any of the documents

If the server is compromised, the attacker could put a bad JS file in the HTML page (which is sent to the user), which will read the contents of the textbox showing the decrypted content, and then send this to $EVIL_HOST

taybenlor• 15 years ago

I'm throwing a rock into the ocean here with all these comments. But I feel like the entire assumption of the article ie "SSL is expensive + hard". Is it really?

All the big companies are making the change to SSL. Sure it may seem expensive, but how many engineer hours will you throw away on cutting those costs? Will those hours have cost you even more? Further: what is the cost if your engineers' implementation is poor and easily broken?

You spend money on SSL, SSL tech gets cheaper and faster. Rinse, repeat.

Or am I missing something?

marshray21• 15 years ago

Usually it depends on how complex and interdependent your site software has become. How many places do you have to find and fix where "http:" was hard coded? How many existing links and web APIs are going to break if you start returning redirects? How many third-party affiliates and SDK partners are going to be affected by your change? Are you going to discard everyone's existing sessions? How are you going to test all this stuff in advance?

tptacek27• 15 years ago

I wrote the article and I don't think TLS is hard.

marshray21• 15 years ago

I'm not trying to be a twit here, but be fair to the site admins: say that after *.matasano.com works fully under https without any mixed-content warnings.

E.g., http://www.matasano.com/ sources http://use.typekit.com/zpb4ovg.js. But there's no https://use.typekit.com. How are you going to fix that? It takes a village.

d2• 15 years ago

Delivering cryptographic software via a network, having it run in a "maleable" runtime and creating a user expectation that it will be secure, is not new.

We've been doing this on the desktop for years.

I'd like to pose a question to the authors:

Don't all the premises you've based "Javascript Cryptography Considered Harmful" on apply equally to downloaded desktop software?

-A chicken egg problem

-A malleable runtime for apps with admin access

-Code verification being defeated by other hostile apps on the system

-Inability to trust the secure keystore because of the chicken-egg problem and other hostile apps installed prior to the crypto app's installation.

-The weakness of pseudo-randomness

yuhong2• 15 years ago

Downloaded desktop software is generally written in a compiled language like C, and for example can't easily be XSSed to inject JavaScript.

__david__2• 15 years ago

Yeah but C has its own problems--buffer overflows and the like. Just because it doesn't have exactly CSS doesn't mean it lacks similar problems.

maaku2• 15 years ago

If you think C programs aren't vulnerable to XSS-like attacks, you need to take a security course.

marshray21• 15 years ago

We've been doing this on the desktop for years.

It didn't hold up well against attack there but there was usually an underlying bit of assumed trustworthiness on the local network that shifted the blame.

But protocols designed for enterprise desktops always turn out to be an unmitigated disaster when run across a hostile internet, particularly from a security perspective.

charlieok2• 15 years ago

Kerberos fits your description ("protocols designed for enterprise desktops") exactly. The hardest thing I've found about running it across a hostile internet is dealing with NAT issues. The (latest version of the) protocol itself is pretty decent from a security perspective.

Then again, the original version of it, when it was designed for enterprise desktops, would not be particularly effective.

cybernytrix• 15 years ago

bit.ly/ndt4ss What does it take to get some attention on HN? Do you have to be part of some secret cabal? I solved all the problems he talks about (and I worked with a crypto guy):

- Statically encrypt and publish content on HTTP server - Transmit these via HTTP to an iframe component at client browser - HTTP-iframe locally sends message to HTTPS-iframe via window.postMessage() - HTTPS-iframe decrypts content (with pre-shared key) and renders it on page

I implemented a library to do this (3 years ago!). Anyone care to tell me just ONE vulnerability with this? Thanks! bit.ly/ndt4ss

nbpoole• 15 years ago

Got a demo set up somewhere?

marshray21• 15 years ago

The unencrypted (or more importantly, unauthenticated) content loading into the iframe is subject to any number of malicious content injection techniques. E.g. http://www.thespanner.co.uk/2007/10/24/iframes-security-summ...

Professional malware distributors seem perfectly happy to obtain placement inside an iframe: http://www.usenix.org/event/hotbots07/tech/full_papers/provo...

Edit: Also, don't you trigger mixed content warnings in the browser?

LogicX• 15 years ago

Since no one has brought it up yet -- I figured I would. The entire time I read this article, I was thinking of Clipperz (https://www.clipperz.com)

Their entire product is based on the model of in-browser cryptography of your credential payload.

You can read more here: http://www.clipperz.com/security_privacy and numerous blog entries, and other articles around the web, but its open source, so you're welcome to review it yourself.

The basic premise is that your browser, through javascript, deals with encrypting and decrypting a blob object which is stored on their server, transmitted via SSL, which they can't read, and can only be read by you when your browser decrypts it with javascript.

I'd love to see the author's take on the Clipperz implementation.

marshray21• 15 years ago

(note: not the author)

At first glance, without going so far as to create an account, they do a lot of stuff right.

I note that the HTTP session cookies set pre-authentication are not 'secure'. I.e., they can be be sent in-the-clear for HTTP connections as well. This may or may not be a real problem in practice.

nikcub• 15 years ago

In the usability/security tradeoff security companies will always try and scare you to the right (they make money doing so). most developers are comfortably being in the middle - after all, do we really need to implement signed client javascript (with all the problems and centralized infrastructure that imposes) just to store todo items?

sullof• 15 years ago

I seem that this article contains a lot of good points about Javascript cryptography. The error of the author is that he is unable to see a reason to build a secure application based on Javascript because his prejudices are too strong. I am the founder of Passpack. We use Javascript cryptography from 2006. We have 16,000 active users and nobody ever reported loss of data. I think that if you are conscious of all the issue connected with browsers and their problems, you can build a good system that is able to protect not only the security of the users but also their privacy. And the privacy can not be protected with a server-based cryptography system.

dave1010uk• 15 years ago

Most browsers (including mobile ones) except IE support the <keygen> HTML element [1]. This creates a "secure" keypair. The public key can be sent to the server and the private key is stored locally somewhere (I guess gnome-keyring, Mac Keychain or Windows registry). I haven't ever seen this in use except in technical demos. While this can't be used for many things where JS encryption is in use, I'm sure it deserves more recognition than it currently has.

[1] https://developer.mozilla.org/En/HTML/Element/keygen

gizzlon• 15 years ago

This alone would not be enough: How do you now the answer you get is coming from the server and not someone who stole the public key?

Javascript Cryptography Considered Harmful

Related Stories