Hacker News Reader

Comment by cortesoft | Hacker News Reader

While these known issues are true, and still need to be worked out, I don't think stopping all work on crypto in the browser is the best course of action.

There are technical ways we could mitigate these vulnerabilities (signing of JS downloaded from a site, for example). Maybe having crypto in the browser become a thing is the way that these features get the support to be implemented.

View on HN

If this were a blog post with a proposal for changes to implement a workable JS crypto mechanism, that'd be great, but it's a actually blog post about how some people are going to implement a "secure" service using a mechanism that's known to be insecure.

This isn't a new idea that we're shooting down before it has a chance to fully form. It's something that people have been trying, and making dangerous security claims about, for at least 10 years.

It's possible that the core issues are resolvable, but they would likely require substantial changes to the way the web browser works. Whenever people start thinking about a way to make a mechanism like this work correctly, the scope of what's required unravels quickly. At this point, I don't know of any defined or even partially articulated proposal that makes sense and accounts for the bulk of the gotchas.

Given that we haven't even been able to get correctly-scopable cookies yet (something the vast majority of the web wants and which has been clearly defined and articulated for many years), I'm not sure that we should hold our breath for this.

No. Crypto is a rare case where broken crypto is actually worse than no crypto at all. When a product claims to have encryption people trust that encryption. If the encryption is not actually effective, that compromises their security. In some cases (e.g. dissidents in oppressive regimes), that gets them killed.

It always comes down to this; would you prefer security, or just something that makes you feel fuzzy? Crypto in JavaScript only gives the latter.

I disagree. Javascript cryptography can provide real security, it's just important to keep in mind what is being secured, and where the vulnerabilities are. Currently, js crypto is vulnerable in that its difficult to verify that the js a browser is running is the intented code.

Every day, millions of people are sending sensitive data over very insecure channels like email and DropBox because secure tools like PGP are to difficult for them or their friends to use. Clearly some security is better than none, as long as the limitations are known.

This is like saying a sign that says "attackers keep out" provides real security, as long as you keep in mind that it only works if attackers obey the sign. After all, Dropbox doesn't have an "attackers keep out" sign!

It is a little better than that. What about an enterprise application where you have control/trust of the server, but want to securely cache data in offline browser storage.

That covers common scenarios, like people who provide web based access to Microsoft Exchange.

No, it's more like an imperfect lock is still more security than no lock at all on your door.

No, it's more like people thinking they have a high grade lock on their door, when in fact they have a broken lock. They can't see it's broken, but anyone who knows about locks knows it's broken, and how to bypass it with a bobby pin.

Is this supposed to be serious, because we want javascript to be better, or sarcastic, because most people DO live behind locks that are broken and can be bypassed trivially with relatively unsophisticated tools? Everybody break out your bobby pins!

You would have extreme trouble picking a lock with a bobby pin, they're much too fat to do anything outside of a movie.

Please note the implications of this. The signed javascript would have to be hosted on a separate third party website, and it would have to be the _only_ script content of the website.

Since code can be executed by almost every resource on a webpage, basically the entire would have to be stored on that separate third party website, the html, the css, maybe throw in the images too given their history of weird exploits.

Not saying that's a very crazy idea, but I'm saying it's way beyond the scope of these opal guys, and probably not what most people 'working out' browser crypto are after.

And yet, jsquery works that way, doesn't it? Everyone pulls jsquery in from basically one site...

Does the entire website have to be on that separate third party location, or just a self-booting kernel of crypto to enable a signed website to be downloaded from the desired source?

> And yet, jsquery works that way, doesn't it? Everyone pulls jsquery in from basically one site...

Not everyone (not even close). Many do, but if I'm running a site over SSL I'm going to be hosting my own copy of the jQuery libs.

Reply on news.ycombinator.com