3 ms·
Sensible post. Yes, doing crypto in the browser is generally harder due to not having direct access to OpenSSL and due to XSS and many other javascript-related
by orthecreedence 13y ago
Sensible post. Yes, doing crypto in the browser is generally harder due to not having direct access to OpenSSL and due to XSS and many other javascript-related vulnerabilities. But if you cover your ass, don't eval code willy-nilly, and package everything into a browser extension (not just your public key or 90% of your JS, but everything) you can mitigate a lot of potential threats. Also, don't try to reinvent SSL. If you do your own crypto in the browser, it should be for peer to peer, not peer to server.
With something like Firefox, you're kind of screwed. For instance, if I open firebug while using my Turtl extension, I can read the contents of memory right there...there's no real separation/sandboxing between extensions. If one extension can read the contents of another, you've got problems. Chrome does this better.
The best way is to package everything into a separate (os-level) app.
- oakwhiz 13y ago>The best way is to package everything into a separate (os-level) app. I agree with this on the premise of threats like XSS, however there is a human aspect of security which might be overlooked. The problem with apps is that everything that is a website today will become a native app tomorrow. App developers might claim that their app is more secure than using a website to do the same thing, because of the included native crypto implementation. Users might then associate any native app with having greater security than a website accessed through a browser (which may not necessarily be true.) Users might become further desensitized to installing everything from the internet as an app. Why is this a problem? Websites normally cannot access things like your personal files, without you explicitly choosing a file from your computer using a file dialog, whereas if you run a native app with your user credentials, it is immediately able to access any file that you have permission to access, without necessarily informing you. Perhaps OS-level security and sandboxing is going to have to improve for this sort of thing to be a good option.
- orthecreedence 13y agoI can see this side of it as well. I tend to come from the camp that if you don't release your code as open-source, you can't really call yourself secure. If you're 100% open-source, distributing a desktop/mobile app will have enough transparency to determine "is it going to steal my CC numbers?" There's also a barrier to entry to get a user to install anything. Mobile is different, but in the desktop world, if I told my users to download the "CNN desktop app!" they'd roll their eyes because why would anyone install some trashy malware-ridden program when they can just look at the website, for free, and as you put it, much safer? From my perspective, the only reason to distribute a "secure" desktop app version of your webapp is if you don't have a webapp to begin with because it's not secure to do so. So the desktop app would be an open-source complement to the browser extensions your secure app uses.
- oakwhiz 13y agoThe products where users seem to preferentially install native apps are services like Dropbox, or video games, where there is value added by not using the "website version." Something that would be very revealing is to investigate how secure these kinds of apps are today. I find it unlikely that in the near future, native app security practices will change very much.
- Natanael 13y agoThe main reason for that is that software very rarely is properly sandboxed by default.