5 ms·
This article is all over the place. First of all calling it "JavaScript cryptography" only to immediately correct itself "oh, we mean browser client-side scrip
by mantraxB 12y ago
This article is all over the place.
First of all calling it "JavaScript cryptography" only to immediately correct itself "oh, we mean browser client-side scripted cryptography, not JavaScript in general, say Node.JS".
Then calling it "cryptography", when all the article talks about is hashing passwords. There's more to cryptography than hashing passwords, and not all of it is susceptible to the attacks described.
So the real title of this article is "Client-side scripted password hashing in browsers less than ideal". I know, doesn't roll off the tongue as sweetly as "JavaScript eats babies", but what you gonna do.
Third, the faulty logic of "this new technique has a bad edge case, so we should completely reject it, despite any benefits".
The article just glosses over the situation where the script is served securely and yet you hash at the client. "We already have a secure connection, anyway" the author claims. Sure, but the server still gets the plain text password, because TLS doesn't hash, it encrypts (and you can decrypt). If the server is passing the login request to a third party to check the hash, turns out it's still a good thing to hash at the client so the intermediating party can't abuse its role, without the horrid UX of OAuth. Has the author thought of that? Nope, just dismissed the potential outright.
Plain old-school TLS/SSL connections have exploitable edge-cases as well. Should we "consider them harmful"?
Intelligent conversations about security require nuanced opinions that go into when something is useful, and when it isn't, and let us make the call if it's harmful or useful for a given project.
Calling something "harmful" outright and only listing the cons without the pros isn't this kind of intelligent conversation. It's just counterproductive scaremongering.
- geertj 12y agoAgreed the article is not very insightful. Another place where it misses the point entirely: > The problem is, having established a secure channel with SSL, you no longer need Javascript cryptography; you have "real" cryptography. This overlooks a major use case of client-based cryptography where you don't want to expose any private keying material to the server.
- davrosthedalek 12y agoNot really. If you don't trust the server to hold the key, you can't trust the client you downloaded from the very same server.
- gnur 12y agoIt's not always about trust. Sometimes it's more about the burden of having the keys. mega is a good example of why client side encryption is used. They don't want the burden / liability of knowing what is stored on their server. (they probably know it anyway, but the idea stands).
- wtbob 12y agoThat protects mega (the server); it does nothing to protect the client. As the client, I care about my protection.
- geertj 12y agoWhile you are correct that a server can serve me malicious Javascript encryption code that discloses my keys, there's a big difference: the act cannot be hidden. If my secret keying material instead is on some company's servers it can be taken surreptitiously (by court order or not).
- geertj 12y agoI'm not sure why HN doesn't let me reply to danielweber's comment. Thread is getting too deep? I admit that in practise you're not going to check the Javascript. But from the point of view of someone trying to get their hands on private material, the difference is huge. If the private material is on a server, a simple court order (or not) can give you access to potentially millions of customer records. But if you wanted to do dragnet collection when client-side crypto is in use, you now have millions of small but non-zero risks to get exposed. [EDIT: spelling]
- danielweber 12y agoWhile it may be mathematically impossible for the server to give you hostile code with no way at all of you detecting it, in practice you are not going to check the JavaScript you download each time. Nor does the browser have any way of doing version control for you, or of verifying what's actually running.
- tptacek 12y agoNo, it does not overlook that "major use case". You're confused between wanting something to work in a specific way, and whether things actually work that way. If there's a "#1 most common fallacious reasoning strategy" employed by advocates of browser crypto, it's that one.
- geertj 12y agoWow, sensitive topic? No need for ad hominem. Thank you very much.
- zimbatm 12y agoI agree that the article fails to expose the main issues properly but JavaScript in the browser, in it's current implementation is harmful. It gives you a false sense of security. The biggest issue is that the crypto code can be changed at any time transparently. It's typically distributed by the same party that has your data so all you're really doing is transferring trust to them.
- tptacek 12y agoThis article has virtually nothing to do with password hashing, but the fact that readers routinely take that away from it is part of why I don't like it much either. We didn't promote it, or post it on HN; I think I posted it to Twitter once, and now people re-find it once a year. I'll absolutely win an argument with you (or, I think, anyone else) about browser Javascript crypto. It's simply a bad idea. I just don't think this particular article will. We don't reject browser Javascript crypto "despite any benefits". We reject it because those benefits are illusory. It's clear that browser crypto makes people feel better, but TSA airport security also makes the majority of Americans feel better too.
- peterbraden 12y agowhat about distributed as signed browser extensions?
- danielweber 12y agoWhat's that Google is working on, and it's a much better environment. The code lives on your computer all the time, and you (in theory, assuming the proper browser settings) can make sure you are using a constant version of the code that matches up with what other people are using and auditing. You can't lock down JavaScript at all. Your browser should (in theory) tell you when a plug-in is asking to be updated and give you the option to say "nope." In theory, you could even walk up to a brand-new (assuming uncompromised) computer and reinstall the plugin. But you would still need some way of knowing that you were installing the same version you decided to trust earlier. Recognizing checksum pictures, I guess?
- xxs 12y agoIt can work but the users have to be able to 'read' the code from the server and sign it themselves. Certain hashes can be considered trustworthy and that would require a 3rd party or being able to put those hashes on paper and compare them.
- tptacek 12y agoI would say that signed browser Javascript extensions are my least favorite place to viably deploy crypto.
- marcosdumay 12y ago> Third, the faulty logic of "this new technique has a bad edge case, so we should completely reject it, despite any benefits". What you are calling an "edge case" is the main feature since the first iteration of the language. That it runs server scripts on the client. And yes, it does mean that it must be completely rejected for crypto code. If the article gloes over something, it's the fact that those problems are fundamental. They can't be ammended, and won't go away at any time in the future. Looks like it should make this still more obvious. I guess that's the second article I upvote on HN... At first I tought "No shit! But I'll take a look", but after reading this kind of responses, yes, I think it should get a few days at the frontpage.