Hacker News Reader

Comment by tptacek | Hacker News Reader

This is a very cool library that is going to be abused far more often than used correctly. In particular:

* In online Internet applications, it can only be delivered safely on pages for which every resource is delivered over HTTPS. Most developers aren't going to see the point of using both HTTPS and JSCrypto. The ones who choose simply to use JSCrypto have totally insecure applications.

* For the task of creating applications with Tarsnap-like insulation between the server and customer data (ie, a backup system where the server can't read your data), this library won't work; any application that delivers this library can in a myriad of subtle and undetectable ways sabotage its security.

View on HN

Witness: An unending series of Stackoverflow questions on doing encryption in Javascript, all of them much like this one: http://stackoverflow.com/questions/1528012/secure-login-publ... .

Ow, my brain. People forget how hostile an environment Javascript is for trusted code. It's not just that you can stage an elaborate man-in-the-middle attack; it's that anything that allows you to run code in the same JS instance can sabotage the encryption. That includes MITM, but it also includes XSS and Javascript injection, JSON injection, and it applies to every source of script and DOM content that builds up the page.

SO should ban all security-related questions. There is too much misinformation and wrong answers get marked as "resolution": http://stackoverflow.com/questions/1702661

The most revealing thing to me was that you can buy an SSL certificate for as little as $30 these days (GoDaddy). It's been a while since I've had to order one for my company, but I seem to recall it costing several hundred dollars the last time I did it.

$30 is expensive; SSL certs have been free for a little while: http://www.startssl.com/?app=1

That's all true, from the client end you cant trust this to stop the server end from snooping your data, but there seems to be a class of problems this approach _does_ solve. Where the guy running the server wants better than just plausible deniability about knowing what his users are storing. It can't guarantee to the "customer" that the "server" can't read his unencrypted data, but it'd probably be as close as you could get to a guarantee for the guy legally responsible for the "server" that he couldn't read (and hence be in any way responsible for) the unencrypted customer data...

I actually have exactly that in one of my products http://www.memengo.com All content is delivered over HTTPS, encryption is in Javascript on the client side. Yes, the user must trust me not to alter the JS code behind their back, but the same applies for any native app that could auto-update and is not guarded by outgoing firewalls. Which is most of them.

The reason why data is encrypted is that database theft (e.g. backup theft) is not a disclosure of data.

Most desktop applications don't automatically update themselves every time you use them.

A lot of apps check for updates on each start, and most users will install an update when prompted. Not everyone, true, but let's talk statistics for now.

Whether developer himself is malicious or his auto-update is hacked, it's a vector to inject harmful code to the user-side environment.

Statistically, there is no practical difference in security of the user's data between a native app and a web app.

I read the title, and optimistically hoped that they were talking about server-side javascript. What are the problems for which symmetric crypto in the browser is the correct solution?

Reply on news.ycombinator.com