4 Comments

  1. Petteri Räty

    Javascript based in-browser encryption provides quite weak guaranties. If someone is able to access data on the server, they are able to modify the javascript so that it sends the information back to the server unencrypted. Your solution just makes accessing your data a little bit more work.

  2. Sven Vermeulen

    Security is a layered thing. You’re absolutely right that write access to the server could/will compromise the confidentiality of the data. However, read access (either on the network or on the server) will not.

    When the site uses SSL/TLS this also protects against attacks like BREACH or CRIME in the sense that session hijacking will not jeopardise the confidentiality.

  3. Anonymous

    I completely agree with Petteri Räty. Other people have explained why JavaScript cryptography is a bad idea far better than it possible in a blog comment. For me the strongest argument is that even if you believe that your JavaScript code is securely delivered to the user as an extension or over a supposedly TLS connection, you can’t defend against timing attack with JavaScript. For Mozilla Firefox there is DOMCrypt and you can load arbitrary library (like OpenSSL, NSS or CryptoAPI). And a W3C Working Group is writing a specification. While I can think of some use cases for this, I don’t think the browser is the right place for applications, especially if they involve cryptography and can compromise privacy.

  4. I didn’t know about DOMCrypt. Good to hear that there is ongoing work on a specification. The idea is the same – in-browser encryption to provide some confidentiality together with session storage. But a more cryptographically secure way than what I did. I’ll be keeping a close eye on that one.

Leave a Reply

Your email address will not be published. Required fields are marked *