On Mon, Mar 4, 2013 at 3:10 PM, Peter Thoenen <[email protected]> wrote: > I'm catching up on this but it's a pretty easy answer. > >> Say you've implemented a bunch of crypto on your web page via Javascript. > > And this is where you went wrong. Don't implement crypto (or anything of > import) client side period (if we are talking web based javascript stuff > here). > Actually, its not too far fetched. In the mobile arena, I see a number of in-house browser based apps that can be side-loaded or distributed through a private or enterprise application store. When using these distribution channels, script injection and tampering is not a high risk because its part of the application bundle.
Organizations like the browsers based and hybrid apps because they are quick to develop, and HTML5 give them all sorts of annoying capabilities, such as reverse proxies via WebSockets. Its yet to be seen if we will get any useful security features for the 'side-loaded web app' model. I wrote to Ian and Alexey (authors of RFC 6455 - WebSockets) and asked for a method to query the underlying connection so I could do unthinkable things such as aborting the connecting or not transmitting the password if the certificate or public key was not expected. I did not hear anything back. Jeff _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
