Filezilla Client seems to ignore my Settings in fzdefaults.xml

[poet]

After 2 days of repairing a hacking attack to some of my Internet-Domains I found out that filezilla stores my passwords in plain text by default.
So I try to avoid this for future now.
I found out that there is a Setting "Kiosk Mode" to control this behaviour.
But when I try to set Kiosk Mode to 1 or 2 instead of 0, my Client seems to ignore this setting.
I uninstalled the old version of Filezilla.
I installed the current version Filezilla 3.5.3 from scratch
Same behaviour.

Do you have any idea, what I could do else to make working my filezilla-client installation accepting my overridings of the default-settings (especially this hacker-friendly password-default-option) by using my fzdefaults.xml, which I located in .../Documents and Settings/<username>/Application Data/Filezilla/ ?

See the content of my fzdefaults.xml below or the full file in attachment
...
<FileZilla3>

<Settings>

<Setting name="Config Location">$SOMEDIR/filezilla/</Setting>
<Setting name="Kiosk mode">2</Setting>
<Setting name="Disable update check">0</Setting>

</Settings>
<Servers>

<Server>

<Host>ftp.gnu.org</Host>
<Port>21</Port>
<Protocol>0</Protocol>
<Type>0</Type>
<Logontype>0</Logontype>
<User>anonymous</User>
<Pass>someone@…</Pass>
<TimezoneOffset>0</TimezoneOffset>
<PasvMode>MODE_DEFAULT</PasvMode>
<MaximumMultipleConnections>0</MaximumMultipleConnections>
<EncodingType>Auto</EncodingType>
<Comments></Comments>
<LocalDir></LocalDir>
<RemoteDir></RemoteDir>Primary GNU download server

</Server>

</Servers>

</FileZilla3>

[poet]

my current fzdefaults.xml

[Tim Kosse]

Note that you can also disable saving of passwords in the settings dialog of FileZilla.

fzdefaults.xml needs to be located in the same directory as filezilla.exe

As the default installation directory of FileZilla is write-protected by Windows against normal users, you may need to acknowledge a UAC prompt or run Explorer elevated.

[poet]

Hi.

1. Thank you for the information to correct location of fzdefaults.xml.

1.a) I tried and it's evident that filezilla follows the settings in this file (kiosk mode=2) now.
The resulting behaviour is as follows:
I start Filezilla, and roundabout 15 (fifteen!) messageboxes to be confirmed seperately are popping up one by one, telling me that writing to a certain file is not possible, until normal working dialog starts.
Same thing when establishing a connection (roundabout five infoboxes)
Same thing when closing (roundabout five infoboxes)
(N.b.: I don't think its a problem of access rights, cause I ran filezilla in windows superuser mode).

1.b) I tried the same thing with kiosk-definition (=1).
The resulting behaviour is exactly the same.

1.c) After all, I think, fzdefaults.xml is no acceptable alternative.
I think, I will forget this fzdefaults.xml-setting and this "kiosk mode". There is a rest of philosophical discourse in my mind about that basically ethic statement of "It's by design, and no bug", but it is really very small.

Then I tried your secont hint and my world changed again. But read first, please:

2. Thank you (really!) for the hint to settings dialogue.

2.a) I found the checkbox to avoid password logging.
When using it for the first time, it worked really well.
"Fine", I thought. There is no longer need to clear the connection list immediately after establishing a connection.
After work, I closed Filezilla Client, checked the log, and no password was found in "recentservers.xml".
"FINE!!!", I thougt. This is a really usable tool, now.

2.b) When I started Filezilla later again, I tried to re-establish a connection from connection-list.
Next action was a popup box inquiring the password, and a checkbox asking for "shall the password be persistent during this session?"
Remembering my desastrous experiences, I thought "No, of course", and unchecked this flagbox.
Ok, fine, clever dialog, I thought.
A little time later I tried a new connection.
And this little checkbox asking for "shall the password be persistent during this session?", was filled again by default, even though I unchecked it before.
"Strange", I thought, Filezilla remembers all settings, but this is reset to default.

Ah-Uhm.

Now I try to find a reasonable explanation, why the designers of filezilla are so eager for inviting users obstinately to make passwords persistent, at least for the duration of a session.

Can you really swear a holy oath (including "betting your life on it" etc.) that the passwords are not made visible outside the core-ram of filezilla-user-space? There is more than little doubt in my mind after all these experience...

But, as said in my conclusion of 2.a), it's a philosophical question now.
"No Password logging"-Setting plus Clearing the Connection-Log seems to be an acceptable work-around.

With grateful regards for your hints,

poet.

[Alexander Schuch]

1) Are you referring to #7186? If yes, please elaborate there.

2) If you upload a queue of files and do not store the password at least for the session, you will be asked for each file to enter the password again. This makes the queuing feature less usable.

Is this bug report solved now in your opinion or are there still issues left?

[poet]

1) closed

2) I see that motivation, but if I had the
CHOICE BETWEEN
2a) being asked for a password more often (i.e. some seconds or minutes of work)
AND
2b) repair several internet-sites of my clients after a viral attack which means at least two days of work (not taken into account the loss of professional reputation coming with such trouble)
THEN I clearly know what I'd prefer.

Finally I think, this is no minor technical problem, but a basic problem of design concerning to security-issues: from my view, storing passwords as uncoded plain text in a readable file should be beyond any acceptance for every professional software engineer concerning to social and economical responsibility.
Sure, it would be a better world if all would be open for (and respected by) everyone, but filezilla better should avoid ANY password feature, then. So I could SEE there is an open door.

What happens, if efficiency issues(in time or money) are rated higher than security or safety issues can be seen very impressively when you refer to ​http://en.wikipedia.org/wiki/Space_Shuttle_Columbia_Disaster#Conclusions

After all, if the responsibles for this "feature" are not willing to re-discuss their SECURITY DESIGN PHILOSOPHY, this ticket can be closed, since for me it's no question of live and death, but just time, money and professional reputation.

With kind regards

poet.

[Alexander Schuch]

I do not get your point for question 2.

If you let FileZilla store the password *for the session*, the password will be kept in memory and not stored on your disk at all (let's ignore swap files for a moment). As soon as you close FileZilla, the password is gone again (let's assume that the OS zeros out memory freed by an application).

I do not see any relevant security issue here.

[Alexander Schuch]

I added a new RFE to store the selection for the session (#8202).

This issue can be closed then.