4 ms·

Unless the JS is served over ssl/tls then it is vulnerable to a MITM modifying the code en-route. Throw in ssl and that fixes that problem. An interesting exa

Unless the JS is served over ssl/tls then it is vulnerable to a MITM modifying the code en-route. Throw in ssl and that fixes that problem. An interesting example of this is glbse.com, it's a bitcoin stock exchange, on the site there is a client python library and a JavaScript client application (to run in the browser). Putting aside how poorly documented (and designed) the JS client is, what they use it for is authentication/authorisation not... for actually encrypting. All requests from the JS client are signed with a RSA private key, the server keeps a copy of the public key, and verifies any incoming requests. The private keys can be stored in html5 local storage (encrypted if you want). The keypairs are initially generated on the server. When they first started making this available it was being served over plain text http, now they use SSL for the reasons above. The idea is to remove the need for servers to store username/password combinations. The users account ID is a sha256 hash of their public key. https://glbse.com https://glbse.com and the JS client https://glbse.com/client/glbse/ https://glbse.com/client/glbse/ as I'd said the UI on this is terrible, but it's something they're working on.

fadzlan 15y ago
That said, as other commenter has mentioned, should the server be compromised, the JS crypto lib may be overwritten with something else that steals the decrypted content in the browser. The thing is, the browser still depends on the server for the crypto implementation EVERYTIME the user logs in to use the application. Native application also suffers from this, since any downloads of the native apps still depends on the hosting server not being compromised. However, the vulnerability only applicable when the application is being download, instead of over and over again in each time of usage as in the case of web application. The only way I can think of is of using extensions. In this manner the trust issue happen once during the download of said extension. By doing this, the implementation would be almost as secure as native application. Almost as secure, because web pages are still content+execution. For the solution to be secure, the pages needs to be secure itself, since other Javascripts or the implementation of the web app could may not protect the user from XSS based attack.(You could say the same about native apps though, as the security depends on how secure is the codes against things like buffer overflow). I personally thinks that it would be the best bet right now.

fadzlan 15y ago

That said, as other commenter has mentioned, should the server be compromised, the JS crypto lib may be overwritten with something else that steals the decrypted content in the browser. The thing is, the browser still depends on the server for the crypto implementation EVERYTIME the user logs in to use the application. Native application also suffers from this, since any downloads of the native apps still depends on the hosting server not being compromised. However, the vulnerability only applicable when the application is being download, instead of over and over again in each time of usage as in the case of web application. The only way I can think of is of using extensions. In this manner the trust issue happen once during the download of said extension. By doing this, the implementation would be almost as secure as native application. Almost as secure, because web pages are still content+execution. For the solution to be secure, the pages needs to be secure itself, since other Javascripts or the implementation of the web app could may not protect the user from XSS based attack.(You could say the same about native apps though, as the security depends on how secure is the codes against things like buffer overflow). I personally thinks that it would be the best bet right now.