= 27d567bc2d48d9f40e9ccc20ea370b15)
g_pepper comments on A pair of free information security tools I wrote - LessWrong
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (97)
Actually, there is still a small danger to executing this via a non-SSL encrypted web site, even if I trust that you have no malicious intent, your site has not been compromised and the script runs client-side. The danger is a man-in-the-middle attack, in which an attacker intercepts my http request for the script and replaces your script (in the response) with a version that captures my private key and sends it to a server controlled by the attacker.
I realize that most browsers won't let client-side javascript send requests to hosts other than the original host from which the javascript was loaded, but that fact won't solve the issue; the modified version of the script could send the private key to a URL apparently on your host, and the man-in-the middle daemon could intercept the request and send it to the attacker's host.
Wouldn't this be circumvented by performing Step 5 followed immediately by Step 4 before running the script? (Of course, the level of inspection necessary to determine what's going on in the script may be high enough that you may as well write your own script by that point.)
Yes, presumably this danger could be mitigated through a combination of code inspection and sandboxing. But, one of Nanashi's stated motivations for developing this was that "I had yet to find an easy way to do this that didn't involve downloading command-line based software". I doubt that anyone who is adverse to running a command-line program would be very excited about inspecting a javascript application for security vulnerabilities and/or sandboxing it each time he/she wants to sign a message.
As much as I dislike blindly following rules in most cases, I think that ChristianKI is correct that any security-related web application ought to be secured via SSL.
I think what I could have been more clear about was the use case here: this tool in its current form is sort of "pre-Alpha". Previously the script was just sitting locally on my computer and I thought it could be useful to others. If I ever try to deploy this on any sort of larger scale, absolutely it will be done on an SSL server. But for right now, it's just being shared amongst a few friends and the LW community.
If it turns out that people are using the tool frequently, I'll probably go ahead and pay to upgrade my hosting plan to SSL. But for something that's a free tool not meant for wide distribution, which takes about 7 seconds to right click and hit "Save As", I just didn't see it as necessary just yet.
Understood. Obtaining an SSL cert is a hassle (and an expense if you obtain it from a cert authority) that may not be warranted for a pre-alpha release. As long as your users use discretion before signing using their "real" private keys, I don't see any issue.
Thanks for making these available; the Decoy app sounds particularly innovative.
The scenario that everyone runs Step 5 and Step 4 everytime they run the script is unrealistic.
It wouldn't be every time you run the script; you would just need to vet it the first time. I expect that anyone using this for serious security purposes would just save the script locally. The point of this is that it's browser-based, not cloud-based. Saving an HTML + Javascript file with a (admittedly rudimentary) GUI is infinitely easier than downloading a command-line based program.