Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cryptography in the Browser

blog.opal.io

Post reply on HN
Print view View original

81–85 of 85 posts

Re: Cryptography in the Browser

#81

Post by zentrus »

ptoomey3 wrote: post #71
dsl wrote: post #65

Earlier quoted context omitted.

> I've gone back and forth in my own head about this argument over the years, and I'm still not entirely sure where I come down I think you are unfairly reframing it as some sort of debate. It's like not being totally decided on if you should log into your server over telnet from a coffee shop. Even if you don't see the weakness, attackers do.

I didn't mean to imply a debate...only that the reductionist viewpoint "it is only as secure as SSL, so just use SSL" doesn't quite sit right with me; the problem feels a bit more grey. In the particular scenario I proposed the only attacker we are trying to protect against is a completely passive attacker than can possibly view our logs from servers along the path to our back end server. Obviously in the world of cr…

I for one agree with you. There are a few specific cases where client-side crypto has benefits regardless of the fact that you need to (at some point) trust the server. I think the best examples involve protecting history or data residing on the server up to the point of being compromised. See my other comment on here for my use case.

Re: Cryptography in the Browser

#82

Post by dyoder »

The negative response to this post is over the top.

At most, you can say that they overstated their case by neglecting to talk about server trust and using the word "comfortable" in an article about security. :)

To address a few red herrings:

Saying that no solution is better than a flawed solution is absurd. There's no such thing as impenetrable security. On that basis, we shouldn't bother with HTTPS. For that matter, we shouldn't bother with passwords, either.

We do these things because they make attacks incrementally more difficult and thus redirect attackers' efforts to more vulnerable targets, or make it expensive enough not to bother. Every little bit helps.

Saying that you can't do this because you have to verify everything on every page load utterly ignores the past decade of development of rich client applications.

Saying that you shouldn't do this because it's been tried before also ignores virtually the entire history of technological innovation.

This is important problem and constructive criticism from security experts is extremely valuable. But the only "sophistry" I'm seeing here is from the people who can help the most.

This is a beta, invite-only app bootstrapped out of the proverbial garage. Their blog post on the technical details missed a few things. If you've ever been in those shoes, you know how easy that is to do. I've seen billion dollar companies do worse. Most of the article was accurate, well-written, and probably helpful to a lot of readers.

Help 'em out, don't tear 'em down.

Re: Cryptography in the Browser

#83

Post by peterwwillis »

tptacek wrote: post #48
peterwwillis wrote: post #38

All browsers already have crypto. Why the fuck are people trying to invent their own when it's built in? http://en.wikipedia.org/wiki/Network_Security_Services https://developer.mozilla.org/en-US/docs/Mozilla_Crypto_FAQ All you need is some kind of new "Web Standard" glue between the browser and the JS and do whatever you feel like using the native crypto functionality of the browser. You don't need to add more layer…

How exactly do you think having built-in AES primitives solves a problem for browser crypto? Content-controlled Javascript still controls how those primitives are used.

First, not all JS delivery is subject to MITM. Having the ability for JS to use built-in, fast, reliable crypto code is useful in many cases. And it's going to be more reliable, and faster, and just better working in all cases by using what's in the browser VS someone's bleeding-edge library based on some other library based on etc etc.

Second, when we get down to it, if you can't trust your content, you can't trust your content. Do you second guess the crypto on your laptop because you might be subject to evil maid or other physical attacks? No, because there is some inherent trust, just like the people who do online banking and shopping. The integrity of the content is important, but not the only issue, and arguably not the highest priority.

Third, what we use the crypto for is completely subjective. Maybe someone using it doesn't care about the integrity of the instructions delivered; it depends on the case. You can't use one case as a yardstick for all of them.

People obviously want to do crypto from JS. I'm not proposing a solution for all the potential problems therein. But if you're going to do it, do it right and use the native code that already is there.

Re: Cryptography in the Browser

#85

Post by simonw »

misterparker wrote: post #67
tptacek wrote: post #29

Earlier quoted context omitted.

No, this doesn't work, because the user still needs to validate the DOM every time the page loads.

What about a site like Passpack? https://www.passpack.com/en/home/ - Does that mean a site like passpack is only waving its hands at its security, and that its client-side cryptography is irrelevant and basically insecure??

Yes, exactly. If Passpack (or a government agency that can force Passpack to obey them) wants to read your passwords they can serve you JavaScript that leaks your secure data as soon as your browser encrypts it.
Post reply on HN