next »

[dhatz]

This is just a quick heads-up for people who may be storing their pfsense config.xml files unencrypted: check to see if your admin login credentials are stored in plain-text format in unrelated fields (e.g. proxypass) of config.xml, due to your browser silently autocompleting them at certain webGUI pages (e.g. System -> Advanced -> Misc).

I've also filed a report at redmine:

Doing a diff between config.xml versions, I noticed that my pfsense's password was stored in plaintext format in
<proxyuser>admin</proxyuser>
<proxypass>password</proxypass>
Checking further, it seems that the Password Manager of my Firefox browser silently auto-completes the proxy username/pass form at System -> Advanced -> Misc

Probably needs a autocomplete="off" to prevent that.

PS: Same problem with the CP voucher webpage last year (which now includes the autocomplete="off" setting).

[Supermule]

Using 1.2.3 and its encrypted.

[dhatz]

Using 1.2.3 and its encrypted.

Just in case I wasn't clear enough, I'm not referring to login info stored in the <user>...</user> section, where passwords are indeed encrypted, but that pfsense login credentials may be inadvertently stored in an unrelated field of config.xml, due to the browser silently autocompleting them in some POST form in the webGUI (see the example I provided above).

[gerdesj]

Using 1.2.3 and its encrypted.

Just in case I wasn't clear enough, I'm not referring to login info stored in the <user>...</user> section, where passwords are indeed encrypted, but that pfsense login credentials may be inadvertently stored in an unrelated field of config.xml, due to the browser silently autocompleting them in some POST form in the webGUI (see the example I provided above).

Also System -> Advanced -> Notifications IP Address (!!!) and Password.  I'm using Chrome.

Cheers
Jon

[ryates]

Interfaces - WAN - PPP (and probably all the others with user and password).

Nearly caught me when about to post my mpd_wan.conf....

[jimp]

I checked in what ended up being a really easy/clean fix.

https://github.com/bsdperimeter/pfsense/commit/fec04267ea5303333839a45149e3cc2edc8250ff

For any page that isn't the login form, all inputs will have autocomplete disabled.

Seems reasonable to me...

[dhatz]

Seems a reasonable solution.

A quick search reveals that there are over 40 references to autocomplete in files in /etc/inc/ and /usr/local/www

[jimp]

Many of those are in javascript libraries and have nothing to do with our code.
And don't count the ones that are manually set to autocomplete=off (they're already disabled)

All that's left is the autocomplete checkbox that controls whether the login form itself allows autocomplete.

So nothing else needs adjusted really, and it's safe to leave the ones that are explicitly set off, off. The code I added (though I fixed the filename) will catch the stragglers/everything else.

[dhatz]

Just happened to notice that the recently commited fix for the autocomplete issue doesn't seem to work under Firefox 3.6.x (3.6.28), which silently autocompletes the form.

[cmb]

Just happened to notice that the recently commited fix for the autocomplete issue doesn't seem to work under Firefox 3.6.x (3.6.28), which silently autocompletes the form.

Considering you're 10 versions outdated there (Firefox v13.x is current), that doesn't surprise me.

[dhatz]

OK, but Firefox 3.6.28 was released just 2 months ago, check http://en.wikipedia.org/wiki/Firefox_3.6

I happened to have it around because I'm using some FF add-ons that don't work in newer versions yet.

[cmb]

We can't fix Firefox. May be one of your extensions, or it may just not support that.

[dhatz]

Doing some checking, it seems that changing line #22 of usr/local/www/fend.inc

from
$("input").prop("autocomplete","off");

to
$("input").attr("autocomplete","off");

makes it work under FF 3.6.28...

[jimp]

I was using attr before, but someone said with the new version of jQuery, prop was the more correct thing to use.

attr worked fine for me initially.

Sure you've cleared your cache and everything? Perhaps your browser cached an older version of jQuery from the firewall.

[dhatz]

Sure you've cleared your cache and everything? Perhaps your browser cached an older version of jQuery from the firewall.

Just verified the reported behavior using ctrl-shift-R (reload overriding cache), autocomplete=off using attr works whereas prop doesn't. Your original commit worked fine when I tried it several days ago, which is why I was puzzled to notice the same issue today.

It's a minor issue, but it shows attention to detail ...