Encrypt stored passwords (using file system facilities; NOT master password)

[Josh]

For Windows Clients, in %appdata%\filezilla\sitemanager.xml the passwords are stored plaintext. This is generally bad security practice, as any malware that is aware of filezilla (as many are aware of and utilize stored passwords in Windows Explorer FTP) can harvest FTP credentials and upload malicious files to any stored webserver FTP addresses.

Windows provides an easy mechanism to encrypt passwords using DPAPI: ​http://msdn.microsoft.com/en-us/library/ms995355.aspx

Specifically, the two functions of interest are CryptProtectData: ​http://msdn.microsoft.com/en-us/library/aa380261.aspx and CryptUnprotectData: ​http://msdn.microsoft.com/en-us/library/aa380261(VS.85).aspx

These functions will handle encryption and key management to store the passwords. They should be used with the optional entropy to further increase the difficulty in other applications extracting that information. If working in .Net the System.Cryptography.ProtectedData class provides managed access to DPAPI so that PINVOKE marshalling is not necessary.

Alternitively sitemanager.xml could be entirely encrypted using AES with the passwords stored in the encrypted file, however the encryption key should be computer/user specific and stored via DPAPI.

Either route comes with drawbacks however - it makes migrating settings to new installs more difficult (can't just copy sitemanager.xml and drop it in the %appdata% directory of the new install) so that is a drawback to be aware of.

In OS X the same functionality is provided via the Keychain API in the functions SecKeychainAddGenericPassword and SecKeychainFindGenericPassword. I am unaware of a linux equivelent

[Bob Trower]

Like another person here, I registered specifically to put in this bug.

There is a long discussion elsewhere about this. Apparently the bug has been there for years. I call this a bug because it is a 'misfeature' that is so severe as to render the program unusable for some purposes. For instance, in my case, I was setting up FileZilla on what has to be a FAT32 USB Flash drive (and hence there is no file-system security). There are about five dozen sites in the XML file in question. There is no way to secure the file using the file system if I move it to the new drive. If I can't secure via a master password, it means I have to store passwords elsewhere in an encrypted file I manage myself. I will then have to go to that encrypted store, open the file up unencrypted using my password, find the relevant password, type it into FileZilla and then securely erase any persistent storage used by the encryption software. It also means that I have to make sure that whenever I move FileZilla that I remember to copy the encryption software plus the relevant encrypted password file.

The above is an extraordinary burden to place on the user. It renders the program either hostile or unsafe and possibly both.

The other discussion kept returning to the argument that in the event of a catastrophic breach by an attacker willing to do whatever it took to breach the system entirely, the system would be breached entirely and therefore a master password would add nothing. Even that is arguably not true since they may still have to sift through logs and divine which keystrokes constitute the master password. Of course, then they also still have to know exactly how to decrypt the file and have the software to do that with. However, the fact that there exist circumstances under which a master password would not be helpful does not imply that a master password is not helpful.

Whoever keeps closing this issue and/or dismissing its importance understands neither security nor logical argument. I apologize for the slam, but it is undeniably true. Making the same mistake over and over does not make it any less of a mistake. The fact that a critical deficiency has existed for years does not make it any less critical a deficiency. Similarly, the fact that there are others (pidgin) who indulge in the same faulty reasoning does not make the reasoning any more sound.

For me, this is now a show stopper. I can't do what I need to do using this tool.

I have been using this tool for years. I was originally aware of this a long time ago, but thought that the issue had been corrected. It was irrelevant since the files were on a secure machine in a secure area behind three firewalls on a secure file system protected by a strong password. I now need to have that facility on a USB drive that cannot be secured except to have individual files encrypted. The natural solution is for programs that will accept and store sensitive data to never store them in the clear. This is the case for any software that has had anyone with a knowledge of security involved.

From a basic discussion about security by the EFF:

The old adage that "a chain is only as strong as its weakest link" applies to security, too: The system as a whole is only as strong as the weakest component. For example, the best door lock is of no use if you have cheap window latches. Encrypting your email so it won't get intercepted in transit won't protect the confidentiality of that email if you store an unencrypted copy on your laptop and your laptop is stolen. ​https://ssd.eff.org/risk/lessons

It is not sound practice for programs to store passwords in the clear. There is no qualifier for that. Software should not store passwords in the clear. The end.

I can not imagine any issue affecting FileZilla that should have as a high a priority as this one. It is a critical security defect and the fact that people dealing with the issue tracking do not understand that and have not understood that for a long time does not make it any less critical. In fact, because this security flaw has existed for a long time it is likely being actively exploited to gain unauthorized access to systems.

The correct fix to this is to always store the file encrypted at least on a previously generated and stored unique salt, then to allow an option to set a master password and then to allow options to export the file and to import a file to allow moving the file.

Whenever the file is being written, retrieve a saved 'salt' value. If it has not been saved, then generate one (uniquely), save it and then retrieve it. Encrypt on the salt plus the master password. When loading, get the salt plus the master password and decrypt. Only store the unencrypted file in RAM. If the salt is stored in the registry and is out of reach of someone who captures your file, they will not be able to decrypt it even if they have the master password.

There is no such thing as absolute security and even the most secure systems are vulnerable to attack. However, that does not mean it makes sense to lower the cost of an attack to the point where the effort required to breach the system is negligible.

Anyone with temporary access to a workstation with FileZilla on it can simply cruise to this page and cut and paste this into a command line and it will display all the passwords in the file:

find "Pass" "%APPDATA%\FileZilla\sitemanager.xml"

They don't even need to know who is logged on.

Encrypting the XML file would not make the program resistant to a strong attack. However, it would certainly make it resistant to the trivial attack above.

[Josh]

Updated to include the thread on FD: ​http://www.gossamer-threads.com/lists/fulldisc/full-disclosure/76111

To address a comment that the FD poster specifically complained about:

"I do not see any harm in storing credentials as long as the rest of your system is properly secure as it should be."

This is an utterly terrible sentiment. There is no such thing as a system properly secured and the person who made that comment is incredibly niave. With the common proliferation of zero day based exploits both malware scanners and product patches are always one step behind through no fault of the user. Finding an unpatched acrobat, flash, or quicktime vulnerability requires no sophistication whatsoever. Filezilla should always adopt the stance that it is a matter of when, rather than if, a system is compromised and design the product accordingly.

The fact is that malware has, for quite a while, adopted the tactic of looking for FTP credentials to upload itself to webservers. To date the focus has been on windows explorer FTP, but just because malware in the past has not felt targetting filezilla to be worth the time does not mean it will continue to believe the product irrelevent forever. When that occurs this product will be complacent in the exploitation. You know that malware targets FTP credentials, you know that the systems you are installed on can't be considered secure, and you know passwords should not be stored in plain text. And now you know that the defect has been posted to full disclosure by someone, and that malware authors do read that list for inspiration. Continueing to ignore this problem is the height of negligence.

The protections are not absolute. A sufficiently advanced form of malware could read the values out of memory while they are in use (though if you really worry about that you could use CryptProtectMemory), though that is highly unlikely. Similarly it could monitor outbound network traffic and sniff the communication, and a host of other techniques. However none of these are anywhere near as easy as simply reading an entirely unprotected and easy to find xml file. There is a huge difference between an exploit scenario that is "Technically doable" and "Trivially easy". Raise the bar a bit.

[Redintray]

Linux client also needs plain text passwords to be encrypted. Protection needs to be able to protect passwords stored in backups of a user's home directory. The simple filesystem directory protection currently used is not a strong enough mechanism for protecting the sitemanager.xml file.

[chinaski]

I can not believe I have been using Filezilla all this time and the passwords were just plain text that can be seen with the Notepad. Plus the Malware can easily use it to upload itself to your hosting.

This has to be fixed asap, before any other feature.

[AUChemist]

Just registered to also voice my concern over this issue. Recently migrated to a new system and found FileZilla's appdata. I was absolutely appalled that my passwords were being stored as plain text. This is absolutely unacceptable. I could ramble on and on about why it is but I think its plainly obvious why.

Developers, please fix this asap!

[Tim Kosse]

Whether passwords are stored encrypted or in plaintext makes no difference in security.

Two options for storing passwords encrypted:
a) Transparent encryption with an implicit master key stored somewhere
b) Encryption with the user required to enter a password to decrypt

In the first scenario, you can just as well use plain text passwords. If no interaction is needed, everybody still access the passwords, even if they are encrypted.

The second option would work, but if you always have to enter some master password, you can instead disable saving of passwords completely.

You can already disable saving of passwords in the settings dialog of FileZilla.

[Redintray]

Ticket closed without full understanding of the implications.

Once Malware takes hold it can easily access files. So, you don't want to store any plaintext passwords on a system. Only store the results of encryption. When a user attempts to login to a remote system do the following: User enters a master password. Filezilla encrypts the entered password and confirms this encrypted password matches what is stored in the file system. This password is then used as a key to decrypt the password store for ftp sites. Using this method even when the machine is compromised the keys are not divulged.

I leave this comment simply as a basis for others to work on - I'm not a security expert but I do know plaintext password storage is a no-no. Filezilla is much less useful to me when I can't confidentially store passwords.

[Josh]

Replying to codesquid:
"Two options for storing passwords encrypted:

a) Transparent encryption with an implicit master key stored somewhere
b) Encryption with the user required to enter a password to decrypt

"

If you had read the original ticket you would see that there is an additional option that I went out of my way to provide you up front. Using DPAPI or Keychain appropriately is NOT remotely the same thing as storing passwords in the clear. They were designed SPECIFICALLY for this situation. You can use them either to store the passwords themselves OR to store a crypto key that is then used to seperately encrypt the password file - in both examples you have protection that is significantly harder to compromise than a key stored on the local system through other means (config file/registry key, hard coded in source, etc). Is it bulletproof and unbreakable? No - but neither are locks/ignition systems on cars but you wouldn't buy a new car that allowed anyone walking by to get in and drive off with it. I absolutely hate the canard that because you can't 100% protect the client you should make no effort to protect it at all; there is rarely unbreakable security regardless of environment, but there certainly is security that is expensive to break and security that is cheap to break. One of those is better than the other.

"The second option would work, but if you always have to enter some master password, you can instead disable saving of passwords completely."

Oh come on - can you really not see that entering one master password once to log into filezilla is not remotely the same thing as entering passwords for every single site stored in the password list? If it was would password managers like LastPass or 1Password make any sense at all? Using a master password, if you want that route over a secure key storage solution like DPAPI, would not be an overly strenous burden on users that want to opt into that solution, and significantly more user friendly than entering every password for every site every time.

---

If you don't want to encrypt the password store in order to make it easy to backup and migrate the password file between installs, or because the best options (DPAPI or Keychain) require platform specific coding (though there is always master passwords or similar non-platform specific implementations), or because you have higher priority feature work or for some other use case that crypto makes more complex that's fine, but at least own that you are choosing that feature/work over a secure implementation rather than throwing out these unnuanced canards to justify ingoring concerns. Malware targets implementations like this specifically because of how trivial it is to get the passwords - it doesn't require much effort on your part to make it a heck of a lot harder for attackers and it can be done in a way mostly transparent or unburdensome to the user.

If nothing else, at least recognize it is a feature that your users are asking for and consider it as a feature request for a future version instead of ignoring it out of hand. That doesn't seem unreasonable

[Rob Janssen]

I also registered just to "+1 vote" this bug (if there were such a feature, it doesn't seem to be so I post a comment).

I can't believe, over the many, many years people have been asking for this this is still not implemented. A simple (heck, make it optional!) master-password will do. Using TrueCrypt or other ways of making sure the file is not easily accessible by malware is all nice 'n stuff but it requires way to much effort for the user. A simple checkbox ("require master password") and a password inputbox is all there's to it.

In the past, what, 5 years I've seen many, many people (and customers) with hacked sites just because this feature is not implemented and, excuse me for being so blut, the developers being too thickheaded to recognise the problem at hand here and helping these people out.

So I would like to +1 joshbw's comment, as with the other comments here and in many other threads online and in this bugtracker.

Please (re)consider your standpoint and at least give users the option to use a masterpassword.

[Alexander Schuch]

See issue #2935 for a "master password approach".

[jordan]

why was this ever rejected? that is so ridiculous.

i had a virus steal the credentials to 5 different sites' ftp accounts and inject malware into them. even notepad++'s ftp plugin encrypts these credentials.

if it takes 2 years to add this ridiculously simple feature, i might as well just stop bothering with filezilla.

[Sam]

Have been a victim using FileZilla. A Trojan manipulated customer websites... very ugly.

I think FileZilla is one of the most beautiful applications.

I missed to check instead of to trust software.

And although there is a mini tutorial to switch FileZilla into more secure kiosk mode, this do not work on my PC.

Is this heavy bug still existing? Seriously?

[jon harper]

+1

[MalwareVictim]

It has happended to me. Tuesday this week my cell phone rang but I couldn't pick it up that moment. When I checked to see who called me, I saw the number of my business partner on the display. He almost never calls me. I thought it was about our tax declaration being due, so I didn't call back because I didn't feel like talking about this topic. I then drove to my office.

In my inbox there was an email by our web host. It said something about suspected malware on our web space, which my business partner had reported. So that was why he tried to reach me... They said they could find any problem on our web space but asked me to check it anyway. So I did...

I first went to the web site presenting one of our products. Within seconds, my anti virus software bombared me with malware alerts and an unwanted file loaded itself down to my desktop. I downloaded the index.htm file using FileZilla to see what was going on. There was a block of cryptic code in it. And not only there, but in every HTML file of that web site! I reported to our web host that the site was obviously totally infected with malware. So much for them not finding a problem with it. But that's a different thing.

Next web site I checked was our company web site: Same thing, malware all over. Meanwhile I answered some emails by upset customers reporting the issue. I also informed my business partner that I was already about to fix everything. We are also running a web forum for our products. Needless to say it was infect too, and so was our landing page for selling our product as well as some web sites still under construction.

Each and every of our web sites were totally contaminated with malicious scripts. Most infected files were HTML files, but certain other files were affected too, like .htaccess, .js, .tpl and sometimes .php files. Thank heavens I had a backup of most web sites, so I could just delete and reupload them. Before I did that, I did an extensive virus scan on my hard drive of course, just to make sure that any new FTP passwords I set would not be stolen again. All this took me hours.

Unfortunately, I did not have a backup of our company web site. That's because I have wanted to revise it anyway for months and thus considered it to be more or less temporary and not worthy of being backed up. So I had to manually remove the malicious blocks of code from hundreds of files. I finished at 3 am and went to bed around 5 am, after a final check for viruses on my hard drive and a message to my business partner and a couple of customers telling them that all viruses had been removed.

I woke up with a terrible headache next day, but was glad that everything was alright again. Or that's what I thought... By chance I found out that a private web site of mine was also infected! How could that be? It was hosted by a free web space provider having nothing to do with our business web site! It occurred to me that I used FileZilla to manage both our business web sites and my private one... But how exactly did the attacker steal my passwords? Maybe he was sniffing around my ports on transmission of the passwords between my machine and the remote server? No! Why not? Because I haven't used FileZilla for several months, neither for our business web sites nor for my private one. All web sites were running fine, so there was no need for FTP. So there is only one answer: The hacker must have stolen the passwords from the XML files stored by FileZilla!

Anyway, it took me another entire working day to also repair my private web site. I finished around 2 am last night, so today I also woke up with a massive headache. Meanwhile I learned that FileZilla does in fact store server passwords in a plain text file without encryption. I also learned that people have been complaing about this for years, and that the developer was refusing to fix that issue. Well, after all, FileZilla is a free software. Free software? I think that in the past 48 hours, I have more than paid for it...

I am using anti virus software and I am regularily doing scans for malware on my machine. So what else can I do to get my system "properly secured"? I am telling you this story to make you think twice. For me, the scenario of FTP passwords getting stolen from FileZilla and an attacker uploading malicious code to one or more web sites using the stolen information is not something that COULD happen. It's something that DID happen to me, and it wreaked havoc on both my business and my private life! I had to cancel business talks, postpone unpaid bills, put customer orders on delay, sacrifice my leisure time and more. Now I hope that the issue is fixed, but I will still have some very busy days clearing the backlog that I am now facing.

I too have just registered hered to file this complaint. FileZilla is otherwise a good piece of software and I like it a lot, but if you have read the above, I am sure you understand why I am saying that FileZilla MUST take appropriate measures to prevent the passwords it stores from being stolen!

[Dean Beedell]

I was previously hacked just as the above chap was - this was years ago and it surprises me that this vulnerability is still present. Ever since then I switched from being a strong advocate to recommending that Windows users avoid filezilla like the plague. I have influenced the decisions of hundreds of potential users in that time. Each person is astounded by the mistake Filezilla developers have made in this respect. There is no question about it, this one flaw is enough for any potential user to drop the program like hot cakes, immediately. It is almost acting as a trojan allowing any hacker to access your sites as long as they can access your PC. Hackers are incredibly clever and resourceful and they see filezilla as an open resource for harvesting passwords en masse.

Since my hack I simply recommend WinSCP as an open source alternative to filezilla. It is superior in many respects and it has in-built encryption controlled via a master password. The developers are also completely open to intelligent suggestion.
I can only reiterate: "Avoid filezilla like the plague - it stores your passwords in plain text, if your PC is hacked all your sites are open to compromise"

[Rob Janssen]

I propose everyone do that: if FileZilla's developers are (and keep being) too thickheaded, and trust me they are/will since this issue has been around for many years in many forms and tickets, we as a community take responsibility to inform current and potential users to avoid FileZilla. It's a shame, because the client is pretty good otherwise. But never, ever, have I met such stubborn developers. Granted, it's *their* project, but never have I seen a devoted and enthousiast community been ignored this hard. Shame, that's the only word that comes to mind.

[busybrian]

My Filezilla was hacked about a year ago. A major headache. What is the issue with adding another layer of security. Is there such a thing as too much security? Security isn't about absolutes, it is about layers. What a major disappointment that the developers don't listen to their customers.

[aciid]

Can not believe this point was raised over 3 years ago and it's not been implemented. Get on the case already! People shouldn't need to explain plaintext implications to developers?

[PanKJ]

I have been in the malware developing industry for a while and I can say that storing passwords as plain text is just unacceptable. To put it simply, the more sophisticated your product is, the more sophisticated the malware has to be in order to exploit it. Writing code to read plain text and upload it is a matter of few minutes. Reading encrypted data on the other hand, not only requires knowledge of how it is encrypted, but also more time.

I would suggest using file system facilities to encrypt settings and connection history as well as the giving the option to use a master password to decrypt the latter. This way malware would find it hard even to know whether a master password is used. As for the argument that ftp passwords can be stolen anyway, just by intercepting the connections, not necessarily will all passwords be stolen. And even if malware developers manage to replicate the functionality that decrypts those files, they will most probably have hard time bruteforcing a master password (high memory/cpu usage attracts too much attention). Only way to open the encrypted files would be logging the password or stealing data directly from memory. But those methods are easier to notice for an antivirus and, in the end of the day, a malware developer has to write code for other functions and other ftp clients, so he might deem it not worth his time.

Being a developer myself I have to say that adding those features should not be too hard. I cannot understand why you give such little importance to security, which is one of the most vital factors nowadays.

[derfder]

I was using FileZilla for several years, but 1 month ago my passwords were stolen. There is no way to encrypt the passwords, so I need to use WinSCP that has a master password. Bye FileZilla ;( !

[webdev]

My machine was compromised and all my FTP passwords stolen from Filezilla. No one should use Filezilla until this has been addressed. It's just not worth the risk.

[hobobobo]

I can not believe that 3 years have passed, and this simple feature not been implemented. It`s not funy. In demand list of my odesk clients (They are managers - not administrators) has item: do not use FileZilla because it is not safe. Time to time I check FileZilla on this feature but nothing.

FileZilla now like a loaded gun that can fire at any moment. This shotgun spread charged. We say - it's dangerous. Developers say - your problems.

[Schweb Design]

Adding our voice here as well.

Per similar bug request here: ​http://trac.filezilla-project.org/ticket/3176
the response was actually:
"This is by design. It's task of the operating system to protect your data.
...

Passwords will stay plaintext. There's no point in obfuscation. As soon as you got access to sitemanager.xml, it doesn't matter if it's plaintext or obfuscated."

WOW!! Isn't that flat out wrong? I would rephrase that to: "as soon as you get access to sitemanager.xml, if the passwords were encrypted there they would either be inaccessible or require the malware to do a lot more work in order to gain access to decrypt, thus protecting your passwords."

Never do i mean to sound ungrateful for great free software like Filezilla, but we also think this is ridiculous and if you think about it could be cascading into more and more harm across the landscape of FTP connected computers and at-risk servers since Filezilla is so popular, widely used, widely trusted.

We have also dropped Filezilla and moved to another FTP program.

[Schweb Design]

didn't mean to change OS for entire ticket.

[IJustDownloadedWinSCP]

Yet Another Register... just for that ticket.

Honestly... I don't care much about security : I use the same passwords on most of the websites I use, I don't have any anti-virus or other paranoïd software installed on my machines, I disable UAC on recent windows since it cripples user experience...

But storing password in PLAIN TEXT ?

No... thats just too much...

I probably wouldn't mind if it was only for my personnal FTP, but such a vulnerability just completely discredits this software for any serious use.

I hope you'll realize how important this is some day...
For the time being, I'll just spread the word.

[angaran]

Please fix this or at least give us an option to securely crypt passwords.

[pkcinna]

It does seem very strange that this serious security bug has not been addressed for so many years on an otherwise great tool. I'm embarrassed for recommending it to my coworkers over the years now that I know the passwords are in plain text. There are so many scenarios where the over simplified argument about "the operating system should handle security" doesn't hold up. Now I understand why no place I have ever worked used FileZilla as the standard. They all use WinSCP.

[klam0]

This bug was is a reason for not using FileZilla any more!

But there is one workaround, to make it (more or less) secure again:
​http://www.trailheadinteractive.com/making_filezilla_ftp_client039s_passwords_more_secure

[localhorst]

I used Filezilla inside a TrueCrypt container, like mentioned above, but this solution wasn't flexible enough and I often kept the volume mounted which exposes the sitemanager.xml anyway.

I found a way to encrypt the sitemanager.xml and decrypt it on runtime. It's the same risk like above, sitemanager.xml is exposed in plaintext as long as Filezilla is open.
But it's a bit more flexible.

​https://github.com/marcus-at-localhorst/encrypted-filezilla-server-settings

[lelegard]

All security engineers following security blogs know that everyday there is a breach somewhere. Often, the breach comes from stolen admin credentials. Considering that FileZilla is otherwise an excellent tool for web admins, storing passwords in the clear is a MAJOR CRITICAL security vulnerability. It is unforgivable to have let this hole open for years, despite several bug reports or feature requests (including this one).

All "solutions" involving external encryption of the config files are insecure workarounds which push the burden to the user. And, as already mentioned in several entries of this bug report, this is not a secure solution; once the encrypted volume is mounted, it becomes accessible to everyone on the system.

So, I developed a very small and simple patch for FileZilla which implements the suggestion of this ticket: use the operating system facilities to encrypt the passwords, both in sitemanager.xml and filezilla.xml (proxy passwords). This patch works on Windows only. The passwords are encrypted using the user's Windows credentials (function CryptProtectData). The structure of the patch allows an easy implementation on other operating systems, using their respective facilities.

The patch is available either as a complete rebuilt installer or as a .patch file for source code.

More details here: ​http://filezilla-wincred-patch.sourceforge.net/index.html

If FileZilla's maintainers agree to integrate this patch into the main line, they will be blessed forever. And if they implement a more secure and portable solution such as a "main password" ala Firefox, they will be blessed for even longer :)

[Tim Kosse]

I don't see any extra security with your patch. Let's assume your system gets compromised with a piece of malware. What prevents the malware from simply reading the encrypted files and calling CryptUnprotectData itself?

And if they implement a more secure and portable solution such as a "main password" ala Firefox, they will be blessed for even longer :)

Note that you can disable saving of passwords in the settings dialog of FileZilla. Think of it as having a main password for each server you connect to. :)

[lelegard]

Replying to codesquid:

I don't see any extra security with your patch.

Feel free to write a better one. Nobody did nothing during 8 years (oldest ticket I found on the subject). At least I did something.

Let's assume your system gets compromised with a piece of malware. What prevents the malware from simply reading the encrypted files and calling CryptUnprotectData itself?

I do agree and I did describe this vulnerability in the description of the patch (link above)

Note that you can disable saving of passwords in the settings dialog of FileZilla. Think of it as having a main password for each server you connect to. :)

Sure, the feature "saving password" is flawed, disable it as a "solution". Great.

[Bob Trower]

Replying to lelegard:

The patch is available either as a complete rebuilt installer or as a .patch file for source code.

More details here: ​http://filezilla-wincred-patch.sourceforge.net/index.html

Thank you for this. This has bugged me for years. I stopped using FileZilla because of this issue, but for years I have followed the bug and it has really irritated me that it is never fixed. It should be clear from this bug report and its many replies over the years that the practice of storing passwords in the clear is improper.
I can't review this right now, but hope to do so later. Even if someone just takes your instructions for building your version so they can add a comprehensive solution, you have made a terrific contribution.

[Tim Kosse]

This is why saving of passwords can be disabled in the settings dialog.

[lelegard]

FileZilla 3.14.0 has been rebuilt with the wincred patch for win64. See ​http://filezilla-wincred-patch.sourceforge.net/

Nothing new, just a rebuilt. Nothing has changed, FileZilla still stores its passwords in the clear. This is pathetic...

[lelegard]

FileZilla 3.15.0.1 has been rebuilt with the wincred patch for win64. See ​​http://filezilla-wincred-patch.sourceforge.net/

Again, nothing new, just a rebuilt, nothing has changed in FileZilla password security.

[Dean Beedell]

Not good enough, I have switched to winSCP which has a much more vigorous security policy. Passwords encrypted by default, master password applied.

[lelegard]

Replying to yereverluvinunclebert:

Not good enough, I have switched to winSCP which has a much more vigorous security policy. Passwords encrypted by default, master password applied.

WinSCP seems much better indeed in terms of security. I did not know it. Thanks for pointing to it.

AES-encrypted passwords in the Windows registry and a PBKDF AES key from a master password is definitely the right solution. I will now use it instead of FileZilla.

[webdev]

Try ​FileZilla Secure ​http://www.filezillasecure.com/ a modified version of FileZilla with master password support.

[Tim Kosse]

Replying to webdev:

Try ​FileZilla Secure ​http://www.filezillasecure.com/ a modified version of FileZilla with master password support.

There are a bunch of security issues with that version:

• Custom AES and SHA implementation instead of using libnettle
• It corrupts large queues due to only using a 32bit integer for file sizes
• Header (de)serialization is not endianess-aware
• It does not handle the case in which the different files use different passwords, silently discarding the user's data
• The iv isn't chosen randomly, encrypting the same data twice yields the same ciphertext
• The ciphertext isn't authenticated, it is possible for an attacker to change parts of the plaintext to his liking, e.g. the stored host where the password is ultimately sent to
• You cannot rely on the code that checks only one instance of FileZilla is running, the settings may be stored on a filesystem that does not support this functionality. It can fail for any number of additional reasons as well
• I haven't looked a the queue storage code yet, probably more issues there as it's a lot of new code

[Dean Beedell]

Well, personally, my suspicious nature, having been bitten once by Filezilla (and very deeply) I have decided not to use it EVER again. I migrated lock, stock and barrel to WinSCP and have never looked back. The developer there engages with his community, is responsive to their demands and the product provides a layer of security that remains unbeaten, at least on my systems. Moving from WSftp to WinSCP is a doddle, migrating from Filezilla was easy and essential.

It is good to hear there is a more protected version. Hope the weaknesses will be addressed.

[Bob Trower]

This issue has finally been dealt with. I downloaded version 3.26.2, set up and connected to an FTP site in sitemanager, added a master password, exited, reloaded, logged onto the site using the master password and it all worked OK. I have not done real testing, but the fact that it passes this reality check means that for my money this particular defect is finally at long last fixed. [Note I have only marked it as 'Fixed' and expect someone else should review and close]

Plenty of problems have lasted for more than seven years in other open source projects. The severity of the impact makes this look exceptional (as security stuff is priority #1). However, despite the optics, this is not really that much of an outlier.

Note 1: It is a bit obscure how to set the master password. As of version 3.26.2, you have to go to Edit->Settings, choose the 'Interface' tab and select the radio button for 'Save passwords protected by a master password'.

Note 2: A couple of months ago, I downloaded and rebuilt the entire 150K+ line codebase, libraries and all for version 3.25.1. This is challenging enough on its own. The directory solely devoted to the build environment, library code, etc has more than 100,000 files in it. I built it to review the code and the work effort to modify and rebuild. It seemed to me that making a change like this is a non-trivial exercise for someone unfamiliar with the code and perhaps even for someone who *is* familiar with it. So ...

Note 3: The Filezilla maintainer deserves credit and thanks for undertaking this task. After these many years it is pretty clear he was reluctant to do this. He stepped up anyway and it looks good on him.

Note 4: The community of people requesting this change and the ones that actually made similar changes to forked code deserve credit as well. I can't imagine this crucial update would have happened without the attention.

Note 5: It should be apparent from the many years of comments that this was a serious, essentially show-stopping defect. Despite arguments to the contrary, adding this level of protection so passwords are not stored in the clear is an absolute must for a program of this type. Every single literate development team storing passwords uses a master password. That should be a clue that experts agree passwords should not be stored in the clear.

Note 6: Finally, anyone who has been following this saga should spread the word. I stopped using Filezilla around the time I made my initial report seven years ago. I can't say that I will switch back, but I am going to give the current version a fair try.