17 ms·

Javascript Cryptography Considered Harmful

207 points by adgar 15y ago

glenjamin 15y 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 15y 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 15y ago
    Also, grandparent assumes the choices are JS crypto and sending passwords in the clear, ignoring the SSL/TLS option.
    - cosgroveb 15y ago
      This seems to happen whenever Javascript crypto is brought up. It's crazy. SSL a little bit of work and it costs $ to purchase a cert (but not very much). It's a bit more CPU overhead on the server but most people have cycles to spare. For the most part SSL should be no big deal. What am I missing here? Are people to cheap to purchase an SSL cert? Theoretically the PKI is only as trustworthy as the CAs but that can't be why people are acting like SSL/TLS isn't even an option.
      - marshray 15y ago
        There are even free certs available from at least one trusted root CA.
- adgar 15y ago
  > Or am I missing something here? You're missing the real solution: SSL/TLS.
- DarkShikari 15y ago
  Timing attacks and other side-channel vulnerabilities.
  - tptacek 15y 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 15y 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.
- amalcon 15y 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.
  - yuhong 15y ago
    Huh? If the session is MitMed, the plaintext password can be revealed, since encryption is not one-way.
hammerdr 15y ago
From the article: "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." 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 15y 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.
benregenspan 15y 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 15y 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.
- tptacek 15y 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.
  - adgar 15y 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.
    - tptacek 15y ago
      I don't even want to think about what the commentary on Reddit is for this.
      - adgar 15y ago
        Well, unlike this thread, it only has 2 people spreading misconceptions and inaccuracies about cryptography. And also unlike this thread, they're heavily downvoted. So there's that.
antimatter15 15y 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.
- amalcon 15y 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?
  - marshray 15y 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.
LiveTheDream 15y 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.
SalmanPK 15y ago
"You could use SSL/TLS to solve this problem, but that's expensive and complicated." This was true 5 years ago not anymore. Get a free certificate today from StartSSL.com or @$7 from RapidSSL.com I haven't seen anyone using "Browser Cryptography" except some newbies, anyone doing that needs to attend some good classes about security.
amalcon 15y 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.
- tptacek 15y 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.
  - marshray 15y ago
    What are the circumstances under which a browser will refuse to run an unsigned Java applet in place of the legitimate signed one?
  - amalcon 15y 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.
- deleted 15y ago
  [deleted]
magikarp 15y 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_hints_and_quintillions.html 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/dlafegoljmjdfmhgoeojifolidmllaie 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.
- adgar 15y 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.
  - magikarp 15y 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.
deleted 15y ago
[deleted]
shazow 15y 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 15y 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 https://glbse.com and the JS client https://glbse.com/client/glbse/ https://glbse.com/client/glbse/ as I'd said the UI on this is terrible, but it's something they're working on.
  - fadzlan 15y 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.
crdoconnor 15y 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.
- marshray 15y 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.
michaelchisari 15y 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:encryption:client-side_encryption 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.
- starwed 15y 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.)
  - michaelchisari 15y 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.
    - jbri 15y ago
      From a user perspective, how would you identify "safely" encrypted elements, in a way that can't by spoofed by the page rendering a nonencrypted element with appropriate styling?
      - michaelchisari 15y ago
        Could be the same way the browser identifies "safely" implemented HTTPS (ie, popup, icon, etc). A nonencrypted element with appropriate styling would not have the same browser-level indications that an encrypted element had.
tzs 15y 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.
- tptacek 15y 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 15y ago
    Put bylines on your articles. You are not The Economist.
    - deleted 15y ago
      [deleted]
- morsch 15y 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.
deleted 15y ago
[deleted]
jwatte 15y 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 15y ago
"___ Considered Harmful" considered harmful.
swah 15y ago
Would be cool if this had an author listed.
- tptacek 15y ago
  Hi.
donpark 15y 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.
- deleted 15y ago
  [deleted]
- marshray 15y 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.
  - donpark 15y 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?
    - marshray 15y ago
      Hacker has to compromise the server Or the connection in between, unless SSL is satisfying that part of our threat model. then, for each connecting user, serve malware javascript. No problem there, that's a core function of a server. It's a feature of MitM tools as well. What's more difficult is an attacker who wants to target only a few specific users. Meanwhile, external network of monitors, masquerading as real users, A nice idea, let me know when you get that implemented. detect that server is compromised and alert the admins who can take appropriate actions. That's always a fun conversation to have. Be prepared for denial, anger, bargaining, and depression before getting to acceptance. Monitor network: "We've found sometimes users are receiving the old version of the Javascript, you know, the buggy one? Particularly when certain key words like 'democracy' occur in the text." Site operator: "Oh, must be an old file on one of the servers." Monitor network: "We think it might be a targeted attack" Site operator: "Well, what are the chances of that" Monitor network: "This is not a random phenomenon like earthquakes" Site operator: "But, you can't prove it, and not all users are affected, right?" ...and so on Overall, compromised server can be shut down in minutes during which only a fraction of user base will have been affected. This scheme should not be confused with actual security. How does this not add to security? More moving parts to break and make things worse. Every bit of script and supplemental page content is another weakest link. And they will break, because they're being developed by those who are ether don't understand or are not willing to admit that they're pushing snake oil, even after the systemic flaws in their scheme have been pointed out repeatedly.
thinner 15y 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.
- marshray 15y 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.
  - thinner 15y ago
    How is it different from advocating standard door locks? I'm not arguing that they should be used for securing bank vaults, all I'm saying is that they serve a useful purpose. If you're trying to say that I'm advocating for jscrypto generally, then that's simply a strawman, because I am obviously not.
tzs 15y 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.
taybenlor 15y 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?
- marshray 15y 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?
- tptacek 15y ago
  I wrote the article and I don't think TLS is hard.
  - marshray 15y 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/ http://www.matasano.com/ sources http://use.typekit.com/zpb4ovg.js http://use.typekit.com/zpb4ovg.js. But there's no https://use.typekit.com https://use.typekit.com. How are you going to fix that? It takes a village.
    - tptacek 15y ago
      Just do be clear: WWW.MATASANO.COM is a static brochure site and we don't do any HTTPS on it at all.
d2 15y 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
- yuhong 15y 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__ 15y 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.
    - tptacek 15y ago
      We're talking about "problems" in the context of "things that make cryptography hard". The other security flaws of C/C++ are orthogonal to this issue. This isn't a value judgement on Javascript. I like Javascript. The hard fact of the matter is, not every good programming environment is going to be suitable for cryptography.
      - __david__ 15y ago
        Perhaps, but almost all buffer overflow, remote code execution bugs are very similar to XSS attacks--feed the program something it doesn't expect along with some junk for it to execute. The mechanism is different but the concept it the same.
cybernytrix 15y 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 15y ago
  Got a demo set up somewhere?
- marshray 15y 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-summary/ 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/provos/provos.pdf http://www.usenix.org/event/hotbots07/tech/full_papers/provo... Edit: Also, don't you trigger mixed content warnings in the browser?
LogicX 15y 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 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 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.
- marshray 15y 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 15y 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 15y 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 15y 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 https://developer.mozilla.org/En/HTML/Element/keygen
- gizzlon 15y 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?

207 points by adgar 15y 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 15y 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 15y ago
  Also, grandparent assumes the choices are JS crypto and sending passwords in the clear, ignoring the SSL/TLS option.
  - cosgroveb 15y ago
    This seems to happen whenever Javascript crypto is brought up. It's crazy. SSL a little bit of work and it costs $ to purchase a cert (but not very much). It's a bit more CPU overhead on the server but most people have cycles to spare. For the most part SSL should be no big deal. What am I missing here? Are people to cheap to purchase an SSL cert? Theoretically the PKI is only as trustworthy as the CAs but that can't be why people are acting like SSL/TLS isn't even an option.
    - marshray 15y ago
      There are even free certs available from at least one trusted root CA.
adgar 15y ago
> Or am I missing something here? You're missing the real solution: SSL/TLS.
DarkShikari 15y ago
Timing attacks and other side-channel vulnerabilities.
- tptacek 15y 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 15y 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.
amalcon 15y 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.
- yuhong 15y ago
  Huh? If the session is MitMed, the plaintext password can be revealed, since encryption is not one-way.

hammerdr 15y ago

From the article: "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." 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 15y 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.

benregenspan 15y 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 15y 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.
tptacek 15y 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.
- adgar 15y 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.
  - tptacek 15y ago
    I don't even want to think about what the commentary on Reddit is for this.
    - adgar 15y ago
      Well, unlike this thread, it only has 2 people spreading misconceptions and inaccuracies about cryptography. And also unlike this thread, they're heavily downvoted. So there's that.

antimatter15 15y 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.

amalcon 15y 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?
- marshray 15y 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.

LiveTheDream 15y 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.

SalmanPK 15y ago

"You could use SSL/TLS to solve this problem, but that's expensive and complicated." This was true 5 years ago not anymore. Get a free certificate today from StartSSL.com or @$7 from RapidSSL.com I haven't seen anyone using "Browser Cryptography" except some newbies, anyone doing that needs to attend some good classes about security.

amalcon 15y 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.

tptacek 15y 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.
- marshray 15y ago
  What are the circumstances under which a browser will refuse to run an unsigned Java applet in place of the legitimate signed one?
- amalcon 15y 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.
deleted 15y ago
[deleted]

magikarp 15y 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_hints_and_quintillions.html 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/dlafegoljmjdfmhgoeojifolidmllaie 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.

adgar 15y 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.
- magikarp 15y 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.

deleted 15y ago

[deleted]

shazow 15y 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 15y 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 https://glbse.com and the JS client https://glbse.com/client/glbse/ https://glbse.com/client/glbse/ as I'd said the UI on this is terrible, but it's something they're working on.
- fadzlan 15y 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.

crdoconnor 15y 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.

marshray 15y 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.

michaelchisari 15y 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:encryption:client-side_encryption 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.

starwed 15y 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.)
- michaelchisari 15y 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.
  - jbri 15y ago
    From a user perspective, how would you identify "safely" encrypted elements, in a way that can't by spoofed by the page rendering a nonencrypted element with appropriate styling?
    - michaelchisari 15y ago
      Could be the same way the browser identifies "safely" implemented HTTPS (ie, popup, icon, etc). A nonencrypted element with appropriate styling would not have the same browser-level indications that an encrypted element had.

tzs 15y 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.

tptacek 15y 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 15y ago
  Put bylines on your articles. You are not The Economist.
  - deleted 15y ago
    [deleted]
morsch 15y 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.

deleted 15y ago

[deleted]

jwatte 15y 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 15y ago

"___ Considered Harmful" considered harmful.

swah 15y ago

Would be cool if this had an author listed.

tptacek 15y ago
Hi.

donpark 15y 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.

deleted 15y ago
[deleted]
marshray 15y 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.
- donpark 15y 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?
  - marshray 15y ago
    Hacker has to compromise the server Or the connection in between, unless SSL is satisfying that part of our threat model. then, for each connecting user, serve malware javascript. No problem there, that's a core function of a server. It's a feature of MitM tools as well. What's more difficult is an attacker who wants to target only a few specific users. Meanwhile, external network of monitors, masquerading as real users, A nice idea, let me know when you get that implemented. detect that server is compromised and alert the admins who can take appropriate actions. That's always a fun conversation to have. Be prepared for denial, anger, bargaining, and depression before getting to acceptance. Monitor network: "We've found sometimes users are receiving the old version of the Javascript, you know, the buggy one? Particularly when certain key words like 'democracy' occur in the text." Site operator: "Oh, must be an old file on one of the servers." Monitor network: "We think it might be a targeted attack" Site operator: "Well, what are the chances of that" Monitor network: "This is not a random phenomenon like earthquakes" Site operator: "But, you can't prove it, and not all users are affected, right?" ...and so on Overall, compromised server can be shut down in minutes during which only a fraction of user base will have been affected. This scheme should not be confused with actual security. How does this not add to security? More moving parts to break and make things worse. Every bit of script and supplemental page content is another weakest link. And they will break, because they're being developed by those who are ether don't understand or are not willing to admit that they're pushing snake oil, even after the systemic flaws in their scheme have been pointed out repeatedly.

thinner 15y 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.

marshray 15y 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.
- thinner 15y ago
  How is it different from advocating standard door locks? I'm not arguing that they should be used for securing bank vaults, all I'm saying is that they serve a useful purpose. If you're trying to say that I'm advocating for jscrypto generally, then that's simply a strawman, because I am obviously not.

tzs 15y 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.

taybenlor 15y 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?

marshray 15y 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?
tptacek 15y ago
I wrote the article and I don't think TLS is hard.
- marshray 15y 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/ http://www.matasano.com/ sources http://use.typekit.com/zpb4ovg.js http://use.typekit.com/zpb4ovg.js. But there's no https://use.typekit.com https://use.typekit.com. How are you going to fix that? It takes a village.
  - tptacek 15y ago
    Just do be clear: WWW.MATASANO.COM is a static brochure site and we don't do any HTTPS on it at all.

d2 15y 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

yuhong 15y 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__ 15y 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.
  - tptacek 15y ago
    We're talking about "problems" in the context of "things that make cryptography hard". The other security flaws of C/C++ are orthogonal to this issue. This isn't a value judgement on Javascript. I like Javascript. The hard fact of the matter is, not every good programming environment is going to be suitable for cryptography.
    - __david__ 15y ago
      Perhaps, but almost all buffer overflow, remote code execution bugs are very similar to XSS attacks--feed the program something it doesn't expect along with some junk for it to execute. The mechanism is different but the concept it the same.

cybernytrix 15y 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 15y ago
Got a demo set up somewhere?
marshray 15y 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-summary/ 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/provos/provos.pdf http://www.usenix.org/event/hotbots07/tech/full_papers/provo... Edit: Also, don't you trigger mixed content warnings in the browser?

LogicX 15y 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 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 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.

marshray 15y 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 15y 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 15y 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 15y 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 https://developer.mozilla.org/En/HTML/Element/keygen

gizzlon 15y 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?