PasswordMaker Forums
Miscellaneous => Other => Topic started by: Eric H. Jung on October 14, 2005, 01:47:52 AM
-
Ok, some people on updates.mozilla.org (https://addons.mozilla.org/extensions/moreinfo.php?id=469) and elsewhere think the online version (http://passwordmaker.org/passwordmaker.html) should use SSL (i.e., https:// ) for some stupid reason. I guess they don't understand that the on-line version (http://passwordmaker.org/passwordmaker.html) doesn't submit anything over the internet; it works client-side only.
So I looked into SSL. The certificate is free from CACerts.org, but the passwordmaker.org ISP requires a static IP address -- $2/month or $24/year.
Should we do it? Bottom line is we live in a world where we must cater to the lowest-common-denominator; in other words, people who either don't have the capacity or time to understand. I want to avoid any future negative press, whether it be in blogs or on updates.mozilla.org.
Anyone have opinions? I'm looking to re-coup most or all of the $24/year from PasswordMaker users. I feel that my donation is the time I put into this stuff, and I've never asked to make a profit--just break-even.
-Eric
-
I understand your point Eric about the lowest common demoninator,
HOWEVER,
and this is not meant to offend anyone nor do I consider myself very knowledgeable in matters of security/progamming/technology (i probably know just enough to get in trouble)
but, the people who don't understand how the online version works are the same people who aren't going to understand or take the time to understand how PM in general works or what it is intended to do
that being said, i think any sort of misunderstanding can and will be corrected through other people who post replies on UMO etc and hopefully, by the new description / website / help pages
so, finally, I say, no, don't go through the whole business and expense
but that's my opinion and we know what those are worth...
-
I guess they don't understand that the on-line version doesn't submit anything over the internet; it works client-side only.
Eric, may be the way the online version works needs to be better explained, so that users will understand that nothing gets submitted. I know that we could download the online version to make it local. So may be we should explain that if they don't trust the online version, they can download it, save it locally, and thereby make it an offline version.
I think if you were to set up SSL, knowledgable people, like the bloggers, the press, etc. would start laughing and give you bad press because you set up the SSL. Those bloggers would presumably understand why and that no SSL is needed and start to question your competence.
-
I kind of agree with both of you therefore I am torn. The guy that did the review over at the Rangers Tale blog said the same about the online version until I corrected him. He literally updated what he had said immediately.
I think the online version is explained exceptionally well but maybe a little more detail could be explained in layman's terms for the not so computer oriented users.
Eric, did you engage in explaining the online version and why there was no need for a secure connection and what was the response?
On the other subject regarding donations, Ive said it before and I'll say it again, don't be afraid to put that donations link back up any time. Most extension authors leave it up year round! IMHO PASSWORDMAKER is priceless and I don't think anyone would think negative about it!
-
Thanks for your replies. I only wish invisionfree would send me emails when people replied to my posts and then I could have replied sooner. Talk about buggy software but I digress...
Eric, did you engage in explaining the online version and why there was no need for a secure connection and what was the response?
I thought I engaged.. This is quoted from the page directly:
Is this page secure?
This page uses only javascript and html to generate passwords. There is no form submission -- purposefully -- so there is no way for the server to see or store your passwords (including the master). It would be a security risk to send passwords over an HTTP (not HTTPS) connection, and also to store them whatsoever (even encrypted) on a server; not to mention a violation of your privacy.
I'm probably assuming to much and think ppl have the time to read the full page. Of course, they don't. I don't read anything "below the fold" of a page 75% of the time or more.
Eric, did you engage in explaining the online version and why there was no need for a secure connection and what was the response?
Are you referring to UMO or a blog? No, I didn't engage.
On the other subject regarding donations, Ive said it before and I'll say it again, don't be afraid to put that donations link back up any time. Most extension authors leave it up year round! IMHO PASSWORDMAKER is priceless and I don't think anyone would think negative about it!
Yeah, I gotta get around to that. It's just a pain in the ass; I'd rather spend the 30 minutes it take me to do that on the website on PasswordMaker instead.
So anyway, I guess we'll skip the SSL stuff for now. Thanks everyone for your feedback.
-
Are you referring to UMO or a blog? No, I didn't engage.
Yes, I assume several people have commented somewhere or other about this and wanted to know if you pointed out the fact to them and what there response was. Was it the same as the response I got from the guy at the Rangers Tale blog.
Again, I think the explanation on the online page is extremely well written. Perhaps we could just add text at the top of the online version page with something like:
*** SEE BOTTOM OF PAGE FOR IMPORTANT INFORMATION REGARDING SECURITY ***
or something to that effect.
-
For best security, both the extension download and the online version should use SSL and an https URL. Otherwise, the door is left open for the following attack:
An attacker inserts his computer into the connection path between the client computer and the PasswordMaker web site (spoofing attack). The attacker then provides a munged version of either the extension or the online version (depending on what the client was requesting). The munged version will contain code to upload the master password to the attacker's web site.
Another way to think about the situation is this: the online version is unique from most javascript downloads in that it asks the user for sensitive data. Because of that and because javascript code has the ability to share that data, the online version must be trusted. The trust can only be established by coming unaltered from a known source, which is https provides.
Note that SSL is insufficient. The attacker could simply use a hacked copy of the PasswordMaker web site with his own SSL. (OK, "simply" is a misstatement: it is usually not easy to inject a site that pretends to be passwordmaker.org - but it is possible, which is why https exists.) The client wouldn't know the server is bogus and would happily chat with it over the SSL connection. The client needs a certificate that it can trace to a root certificate authority that authenticates the server. Can you get that free from CACerts.org? If not, it might cost hundreds of dollars to get one. :(
Now here is an interesting twist. Let's say you decide to secure the PasswordMaker web site with https. The common user still won't be secure. The problem is that the mozilla web site itself is insecure! That is, if the user clicks Install Now from the Mozilla PasswordMaker (https://addons.mozilla.org/extensions/moreinfo.php?id=469) page, he gets an insecure download link (http://ftp.mozilla.org/pub/mozilla.org/extensions/passwordmaker/passwordmaker-0.8.7-fx+mz+ns.xpi). I wonder if automatic updates work the same way.
Futhermore, there may be an additional vulnerability, depending on Firefox's sandboxing model. If extensions are allowed to access data from other extensions (even private data using introspection), any other extension could access the master password stored in PasswordMaker. That would mean users would need to trust all extensions to the same degree that they do PasswordMaker. Hopefully, Firefox is already designed to isolate extensions, but it would be worth verifying and reporting, if not.
My bottom line recommendation would be to switch to https if practical (i.e. the authentication certificate isn't too expensive) and report the vulnerability of the Mozilla download (http://ftp.mozilla.org/pub/mozilla.org/extensions/passwordmaker/passwordmaker-0.8.7-fx+mz+ns.xpi). The other way of looking at it is to say, well, there's no point until Mozilla gets its act together. This is largely a value judgment, similar to the political question of whether a country should bother outlawing harmful internet content even if similar content would still be available due to its legality in other countries. My personal values tend me toward doing what I think is best if it is practical for me to implement - even if there is little immediate practical value - as a matter of principle and to set an example for others.
-
Thanks for the feedback. I've decided to go for it, but to keep costs down we'll use the cert from CACerts.org. Unfortunately, they are not recognized by most existing browsers as a valid CA.
-
I know this is a bit after the fact, but...
Unfortunately, they are not recognized by most existing browsers as a valid CA.
Including Firefox.
It doesn't do much good to add SSL to calm people's concerns, if Firefox comes out and says "this browser has no idea if passwordmaker.org can be trusted." Also, anyone who does read the info on security will start to question it twice more with the current setup. First off, if it is truly secure, why would it need SSL? Having a secure connection for a javascript form that doesn't need it does tend to look funny. Also, seeing as Firefox itself doesn't trust it...
click to see a larger version (http://static.flickr.com/25/52560402_a367dacb63_o.png)
(http://static.flickr.com/25/52560402_a367dacb63_t.jpg)
-
I know about the certificate warning. It's because CACerts isn't a recognized authority. In Firefox 1.0.7, there are only 39 trusted authorities in the entire world. What a joke.
I was about to tell people to just deal with it until I saw the warning pop-up (http://static.flickr.com/25/52560402_a367dacb63_o.png) when I wasn't even navigating passwordmaker.org. Then I remembered that Firefox periodically hits http://passwordmaker.org/update.rdf (http://passwordmaker.org/update.xml) to check for updates to the extension. So now people will see this message and probably think their passwords are being uploaded to passwordmaker.org or something nefarious.
I'll splurge for a certificate from one of the 39 trusted authorities, at least for a year. We'll see if it's still worth it after that.
-Eric
-
Got a cert from godaddy.com for $29.95. Unbelievable price. The CA is Starfield Tech (they're actually owned by GoDaddy), which both IE and Firefox trust by default. It should be installed soon, replacing the one from CACerts.org.
An attacker inserts his computer into the connection path between the client computer and the PasswordMaker web site (spoofing attack). The attacker then provides a munged version of either the extension or the online version (depending on what the client was requesting). The munged version will contain code to upload the master password to the attacker's web site.
I believe this kind of attack can no longer happen now.
update: The new certificate is now in use.
-
When I go the the secure online version (https://passwordmaker.org/passwordmaker.html), I get the warning pop-up (http://static.flickr.com/25/52560402_a367dacb63_o.png). Same goes for the xpi download.
Another issue is that since there are no links or redirects to the secure URLs, no one will know they exist, short of trying them manually. Perhaps you are just waiting to make sure everything works before switching over.
At the risk of stating the obvious, when you do hook in the https pages, for performance you should consider only linking to https for the online version (https://passwordmaker.org/passwordmaker.html), the downloads (xpi (https://passwordmaker.org/downloads/passwdmaker-0.8.7.xpi), etc.), and probably update.rdf (probably need to tweak the next version of PasswordMaker to use the https URL to update.rdf). All other pages are fine with just http, since they are not security sensitive as far as I know.
-
I'll disabled automatic redirect to HTTPS temporarily since there are problems with the warning pop-up still.
As for only linking the online version, xpi, and update.rdf, I'll see what I can do but I'm not sure my mod_rewrite skills are up-to-par for that yet.
Thanks for the feedback!
Eric
-
mod_rewrite skills you say? I might be able to offer some help.
-
Thank you! I'll PM the rules I need...
-
A quick thought: Is is possible to digitally sign an xpi file? If so, then the xpi download doesn't need SSL. The same idea applies to the Konfabulator Widget, too. Ideally, the only portion of the site that would need SSL is the online version.
The other plus of digitially signing is that mirrors (e.g. Mozilla's extension site) would not need SSL, nor would there be any concern of the xpi being altered during the mirroring process.
-
mod_rewrite skills you say? I might be able to offer some help.
I decided not to PM the rules but instead post them here. Here are the rules I wrote to redirect all traffic from HTTP to HTTPS:
RewriteCond %{SERVER_PORT} =80 [OR]
RewriteCond %{HTTP_HOST} !^passwordmaker\.org$ [NC]
RewriteRule ^.*$ https://passwordmaker.org%{REQUEST_URI} [L,R=301]
But as breyed points out, we only need four pages to redirect to HTTPS. Those pages are:- http://passwordmaker/installation.html
- http://passwordmaker/installation2.html
- http://passwordmaker.org/passwordmaker.html
- http://passwordmaker.org/konfabulator.html
I also need a rule to redirect www.passwordmaker.org to passwordmaker.org and, infact, *.passwordmaker.org to passwordmaker.org. I thought this would do it:
RewriteCond %{HTTP_HOST} !^passwordmaker\.org$ [NC]
RewriteRule ^.*$ http://passwordmaker.org%{REQUEST_URI} [L,R=301]
A quick thought: Is is possible to digitally sign an xpi file?
It is possible but quite involved and something I'm not willing to tackle right now. If you like, I can post MD-5 and/or SHA-1 hash values for the downloads. I'd also like to point out that http://addons.mozilla.org (http://addons.mozilla.org) does now redirect to https://addons.mozilla.org, although in the past this didn't always occur. Perhaps some of the mirrors didn't have their mod_rewrite rules synchronized.
Thanks for any assistance with the mod_rewrite rules.
-Eric
-
I'll look into this. If you don't get a response from me tomorrow, there's a good chance I'm yelling at my phone company Thursday for not having my phone on at home by the deadline they told me last week. (Tomorrow will mark two weeks without phone service)
-
Thanks. Add
http://passwordmaker/ie.html (http://passwordmaker/ie.html) to the list.
-
Was planning on it. Might make it easy to add any url in the future if I do it right.
-
Thanks. Add
http://passwordmaker/ie.html (http://passwordmaker/ie.html) to the list.
"Eirc,"
Is this a HEADS-UP that IE is next?
-
A beta version of the IE edition was released last night. See here (http://forums.passwordmaker.org/index.php?showtopic=533) and here (http://passwordmaker.org/news.html).
-
I made it, and it only redirects the pages you want to HTTPS and the rest to HTTP. You just need to keep the list up to date your self. And you can remove the '^/' bit if it doesn't work (my dev server didn't have those files in the root, but in a subdirectory, so I had to test without the '^/' bit anyway)
RewriteEngine on
#Domain redirect
RewriteCond %{HTTP_HOST} !^passwordmaker\.org$ [NC]
RewriteRule .* http://passwordmaker\.org%{REQUEST_URI} [L,R=301]
# Redirects to HTTPS
RewriteCond %{SERVER_PORT} 80
RewriteCond %{REQUEST_URI} ^/installation.html$ [OR]
RewriteCond %{REQUEST_URI} ^/installation2.html$ [OR]
RewriteCond %{REQUEST_URI} ^/passwordmaker.html$ [OR]
RewriteCond %{REQUEST_URI} ^/konfabulator.html$ [OR]
RewriteCond %{REQUEST_URI} ^/ie.html$
RewriteRule .* https://passwordmaker\.org%{REQUEST_URI} [L,R=301]
# Redirects the pages that shouldn't be HTTPS to HTTP
# Note the lack of [OR]
RewriteCond %{SERVER_PORT} !80
RewriteCond %{REQUEST_URI} !^/installation.html$
RewriteCond %{REQUEST_URI} !^/installation2.html$
RewriteCond %{REQUEST_URI} !^/passwordmaker.html$
RewriteCond %{REQUEST_URI} !^/konfabulator.html$
RewriteCond %{REQUEST_URI} !^/ie.html$
RewriteRule .* http://passwordmaker\.org%{REQUEST_URI} [L,R=301]
-
Thanks. Unfortunately, the passwordmaker.org ISP has not been able to install the SSL certificates such that the security warning goes away in FF/Mozilla/Netscape. It does not appear in IE, though. Give it a try:
https://passwordmaker.org (https://passwordmaker.org)
Try it in FF/Mozilla/Netscape... see the security warning, then try in IE (if you have it). You won't see the security warning.
Until that warning goes away, it's unlikely I'll put the mod_rewrite rules in place. And given that the ISP has essentially 'given up'...it's unlikely to happen at all. If anyone else wants to take up the fight with them, I'd be glad to hand over the reigns. I'm completely burned out dealing with them.
-
Where did you get the Cert fromificate from? Firefox doesn't know it.
-
To put the security issue with PasswordMaker in light of the broader topic of Firefox security security, here is an old, but still relavent article on Firefox security (http://blogs.msdn.com/ptorr/archive/2004/12/20/327511.aspx). Check out the follow-up, too.
-
Where did you get the Cert fromificate from? Firefox doesn't know it.
Starfield Tech. There's a discussion going on here (http://forums.asmallorange.com/index.php?showtopic=4858) about this. Someone else claims it works fine for him in FF 1.0.7.
-
It should be working now. Give it a try and let me know: https://passwordmaker.org (https://passwordmaker.org)
-
"Eric,"
It works fine for me to access the site for downloading. I went to https://passwordmaker.org/ie.html (https://passwordmaker.org/ie.html) .
-
Works great now. No warning message about accepting the certificate.
-
I made it, and it only redirects the pages you want to HTTPS and the rest to HTTP.
Uploaded to the site, and seems to be working great! Thanks again, miquelfire!
-Eric
-
Miquelfire (or anyone else), any idea why those rules make http://passwordmaker.org/proto/test34.xul (http://passwordmaker.org/proto/test34.xul) redirect to https://?
That URL is discussed here (http://forums.passwordmaker.org/index.php?showtopic=164).
-
No clue. From what I see, that page should be redirected to http if https is used. Did you change something when you posted it?
-
Turns out the /proto directory had its own .htaccess file with rules causing the redirect to https. I think I was using it as a test directory some time ago.
By the way, do you know why, when I visit https://passwordmaker.org/passwordmaker.html (https://passwordmaker.org/passwordmaker.html), I'm told the page contains secure and non-secure elements? (You might have to use a new profile to see this message if you've told your browser not to show it to again). My guess is it's because the page has code like this:
<link rel="stylesheet" href="/common.css" type="text/css"/>
<script src="/scripts/common.js" type="text/javascript"></script>
...
those files, when requested by the browser, are forced to be downloaded using http:// because of these rules:
# Redirects the pages that shouldn't be HTTPS to HTTP
# Note the lack of [OR]
RewriteCond %{SERVER_PORT} !80
RewriteCond %{REQUEST_URI} !^/installation.html$
RewriteCond %{REQUEST_URI} !^/installation2.html$
RewriteCond %{REQUEST_URI} !^/passwordmaker.html$
RewriteCond %{REQUEST_URI} !^/konfabulator.html$
RewriteCond %{REQUEST_URI} !^/ie.html$
RewriteRule .* http://passwordmaker\.org%{REQUEST_URI} [L,R=301]
What do you think?
-
Hmm, maybe remove the forcing of the http redirects for now. I can't see a way to force people to use http unless you edit the links to use http all the time for HTML pages. Or have it so that only .html pages are forced to redirect to HTTP by replacing the RewriteRule line with:
RewriteRule.*\.html http://passwordmaker\.org%{REQUEST_URI} [L,R=301]
Oh yea, just noticed this, a path of /installationXhtml will be forced to HTTPS with the current rules because I didn't escape the '.'
-
How do I escape '.'? Like this: '\.'?
-
Yep.
And you been programming Javascript for how long?
-
And you been programming Javascript for how long?
I started yesterday. I can write websites now!
-
Oh yea, just noticed this, a path of /installationXhtml will be forced to HTTPS with the current rules because I didn't escape the '.'
The examples in the 1.3 mod_rewrite docs (http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html) don't use \. in URIs. For instace (end of RewriteCond):
Example:
To rewrite the Homepage of a site according to the ``User-Agent:'' header of the request, you can use the following:
RewriteCond %{HTTP_USER_AGENT} ^Mozilla.*
RewriteRule ^/$ /homepage.max.html [L]
RewriteCond %{HTTP_USER_AGENT} ^Lynx.*
RewriteRule ^/$ /homepage.min.html [L]
RewriteRule ^/$ /homepage.std.html [L]
Or have it so that only .html pages are forced to redirect to HTTP by replacing the RewriteRule line with:
RewriteRule.*\.html http://passwordmaker\.org%{REQUEST_URI} [L,R=301]
I've done this, and still get the warning (http://img134.imageshack.us/img134/9420/capture1103200511550pm3df.jpg). When I click Tools->Page Info->Media to see which resources weren't downloaded using SSL, the offending resource is always http://passwordmaker.org/images/li.gif (http://passwordmaker.org/images/li.gif) -- no matter what the page. Here is my compelte .htaccess file. Do you see anything that might be causing this?
AddType text/xml .rdf
AddType text/html .xhtml
AddHandler server-parsed .xhtml
AddHandler application/x-httpd-php .htm .html .xhtml
Options All -Indexes
RewriteEngine on
# Don't steal our content
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https://passwordmaker.org/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^https://passwordmaker.org$ [NC]
RewriteCond %{HTTP_REFERER} !^http://passwordmaker.org/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://passwordmaker.org$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.passwordmaker.org/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.passwordmaker.org$ [NC]
RewriteCond %{HTTP_REFERER} !^http://forums.passwordmaker.org/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://forums.passwordmaker.org$ [NC]
RewriteCond %{HTTP_REFERER} !^http://s11.invisionfree.com/PasswordMaker/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://s11.invisionfree.com/PasswordMaker$ [NC]
RewriteRule .*\.(jpg|jpeg|gif|png|bmp|xpi)$ - [F,NC]
#Domain redirect
RewriteCond %{HTTP_HOST} !^passwordmaker\.org$ [NC]
RewriteRule .* http://passwordmaker\.org%{REQUEST_URI} [L,R=301]
# Redirects to HTTPS - thanks miquelfire
RewriteCond %{SERVER_PORT} 80
RewriteCond %{REQUEST_URI} ^/installation\.html$ [OR]
RewriteCond %{REQUEST_URI} ^/installation2\.html$ [OR]
RewriteCond %{REQUEST_URI} ^/passwordmaker\.html$ [OR]
RewriteCond %{REQUEST_URI} ^/konfabulator\.html$ [OR]
RewriteCond %{REQUEST_URI} ^/ie\.html$
RewriteRule .*\.html https://passwordmaker\.org%{REQUEST_URI} [L,R=301]
# Redirects the pages that shouldn't be HTTPS to HTTP - thanks miquelfire
# Note the lack of [OR]
RewriteCond %{SERVER_PORT} !80
RewriteCond %{REQUEST_URI} !^/installation\.html$
RewriteCond %{REQUEST_URI} !^/installation2\.html$
RewriteCond %{REQUEST_URI} !^/passwordmaker\.html$
RewriteCond %{REQUEST_URI} !^/konfabulator\.html$
RewriteCond %{REQUEST_URI} !^/ie\.html$
RewriteRule .* http://passwordmaker\.org%{REQUEST_URI} [L,R=301]
Thanks,
Eric
-
RewriteRule .*\.html https://passwordmaker\.org%{REQUEST_URI} (https://passwordmaker\.org%{REQUEST_URI})
This prevents xhtml pages from redirecting to http://. Go to https://passwordmaker.org/ie.html (https://passwordmaker.org/ie.html) then click on Manual->Introduction. This should change back to HTTP...
-
The final one needs the .*\.html part as well.
-
Nah, didn't fix it.
-
# Redirects the pages that shouldn't be HTTPS to HTTP - thanks miquelfire
# Note the lack of [OR]
RewriteCond %{SERVER_PORT} !80
RewriteCond %{REQUEST_URI} !^/installation\.html$
RewriteCond %{REQUEST_URI} !^/installation2\.html$
RewriteCond %{REQUEST_URI} !^/passwordmaker\.html$
RewriteCond %{REQUEST_URI} !^/konfabulator\.html$
RewriteCond %{REQUEST_URI} !^/ie\.html$
RewriteRule .*\.html$ http://passwordmaker\.org%{REQUEST_URI} [L,R=301]That should make it so that only html files will work. I'll check it out at home and see what I can come up with.
Note: I noticed that the redirects gets into your broswer's cache, which makes it a pain to debug.
-
That should make it so that only html files will work. I'll check it out at home and see what I can come up with.
I know, but I need it to work for .xhtml pages, too; e.g.,
RewriteRule .*\.?html$ http://passwordmaker\.org%{REQUEST_URI}]http://passwordmaker\.org%{REQUEST_URI} [L,R=301]
I'll just try that.
-
Wrong, I think you meant to include a x before hand.
#easy way to add extensions, just a list of pipe separated extensions
RewriteRule .*\.(html|xhtml)$ http://passwordmaker\.org%{REQUEST_URI}]http://passwordmaker\.org%{REQUEST_URI} [L,R=301]