Fabio dont get me wrong, I absolutely share your enthusiasm and see HTML5 as a great open standard. The apps will run on any device and the time to market is quicker because of that. Thats a great step forward!
But I share tom's scepticism. Just because everybody is using a tool, does not by definition mean it's the right tool for the job. HTML/JS is very flexible and we enjoy that flexibility as developers, but this does introduce possible loopholes. The question is, from the vulnerabilies listed that cannot be fixed easily, which are an acceptable risk for an application like pgpbox? Let me try to answer: > Third-Party Problem: Any third party supplying code can poison the runtime Well right now (besides openpgp.js of course) pgpbox is using jquery, jquery ui (and possibly jquery file upload), pdf.js is only there for experimentation and will probably get dropped in a stable release. > XSS Problem: Any XSS flaw can poison the runtime That's definitely a possible risk. I am not an expert in that field. So a code review might make sense here. If anyone can point me in the direction of some good literature which explains what to look for, I would be very grateful. > MITM Problem: Without SSL the code can be easily modified I set up a security constraint, so that all requests to /app/* must go over https > SSL Problem: SSL Authentication (CAs) blows :) > Modified Problem: Have to validate the runtime each new pageload That could prove difficult. This risk would probably have to be accepted at the moment. > RNG Problem: Javascript doesn't have a secure RNG Well I testes pgpbox+openpgp.js on a number of browsers. It fails on the ones that dont have window.crypto.getRandomValues() implemented e.g. Firefox. Chrome, iOS 5, and Android 4.0 work. Although you're right. One would have to assess how good those rng really are. > Implementation Problem: Shouldn't write your own crypto > Keystore Problem: Where do you keep your keys? I see this as a major issue with the current version of openpgp.js as well. I can only generate private keys without a passphrase. And once I've generated it, I store it in localstorage where potentially any web app could access it. > Side Channel Problem: Timing and other attacks Again, not my area of expertise. > Coercible Problem: Has the entity you used to trust still trustworthy? Well the entity Im trusting is the server that I downloaded the app from. Once its been compromised, an attacker could serve me code that reads my insecure keystore and then decrypt my files. Thats a major issue. One way to guard against this would be to reduce the number of "installs" by using something like phonegap. > Cache Problem: Has your cache been tampered with or poisoned? I dont cache in localstorage other than the keys, so Im not quite sure how this applies.
_______________________________________________ http://openpgpjs.org
