It turns out that FileZilla already had some problems with its storing of the passwords in its Site Manager, a feature allowing the user to memorize his favorite servers into the software’s configuration and log into them with a single click rather than reentering the password manually. It is obviously a given that storing passwords is (most of the time) less secure than having to reenter them manually, but for most users, it isn’t really convenient, especially if they have to connect to the same server several times a day, which is why many software, not just FTP ones, have such facilities implemented. I wrote “most of the time” because if the user’s machine is infected by a keylogger, inputing the passwords is likely to disclose them, but if that’s the case, the user has bigger problems already anyway. So, FileZilla was previously storing these passwords using a weak obfuscation scheme: as a result, many tools were available to recover the FileZilla passwords, and some security researchers eventually published an advisory about that… because that’s their job. The reaction of the FileZilla’s main developer was rather quite surprising as rather than improving and strengthening the method storing these passwords as much as he could, he decided to give up any effort towards this security issue and store them as plain-text in mere .xml files. I assume that the rationale behind this move is that the way the passwords were stored was bound to be discovered again (especially considering the source code is available): it was just a matter of time, but I really wonder what can be worse than plain-text anyway? His reaction towards the advisory is also rather worrying as he just brushes it off as simply being “non-sense” in a post in the product’s official forum, in reply to a worried user: when a software developer consider security advisories as non-sense, there are reasons for the users to worry.

Possibly even more worrying, the developer then tries to pass the burden of the security of his own product to the underlying Operating System under the belief that “It's task of the operating system to protect your private data.”
I certainly see the logic here but there are different degrees of privacy regarding data and passwords is probably a high-privacy thing, and at any rate this kind of renouncement is far from being a security principle widely supported by the community. The problem is that it is easy to get access to that data of a system without knowing the logon password. Booting the system from a Linux or BartPE/WinPE BootCD is usually enough. Of course, there are technologies to counter those scenarios (NTFS EFS, BitLocker, TrueCrypt and others) but they are solutions that come with their share of inconveniences and downsides and require some technical knowledge for, first understanding their implications, and then, implementing them. I am not sure that this kind of prerequisite is really acceptable to use a simple FTP software in a relatively safe manner.

At any rate, between a clear-text password and an obfuscated/encrypted, but clearly not inviolable password storage system, which one would you chose? More decent arguments the author could have put forth would have been that this kind of basic encryption gives a false sense of security while there are tools out there who can give you the passwords in a matter of seconds. The problem is that there is no warning when the user inputs his password in the Site Manager window warning him that his credentials are going to be stored as clear-text! Another argument could have been that FTP is insecure by design as the password is sent to the server in clear-text anyway and that a mere packet sniffer can intercept it, but having different ways to easily get the password doesn’t mean that getting the password in a different way should be equally easy. At any rate, a packet sniffer will have an hard time to decipher the password on a encrypted FTPS or SFTP session, and yet, the password is still stored as clear-text in FileZilla’s configuration file for those supposedly secure FTP sessions…

The worse-case scenario probably is when using the Portable version of FileZilla. In this situation, the passwords are on your USB stick and if you lose it or forget it somewhere, everyone can read your password: it is as easy as opening an XML file. Granted, even if the passwords were stored, they could just open FileZilla and connect through the Site Manager feature and do as much damage or get as much data as it is possible to do with this particular login.

I could give a dozen way of how to steal the FTP passwords and while none of them is difficult for any person with some IT experience and knowledge, it doesn’t mean it should be made as easy as possible. Storing passwords is insecure by design, even more so when storing them as a salted hash is not possible, which is often the case for clients, but that doesn’t mean the job should be made as easy as possible for anyone wanting to know your FTP password. The NirSoft website has countless compact and easy-to-use utilities to recover passwords from applications such as Microsoft Outlook, Mozilla Firefox or Google Chrome… yet none of these products’ developers gave up and decided to store the password as clear-text as it still makes the job (slightly) harder in some scenarios and depending on how secure the communication protocols used by these software are themselves. More than the actual danger, I have been frustrated by how little importance the FileZilla’s authors give to security concerns: I’m surprised that in 2009, software developers can still think that way as security is one of the biggest focus in software engineering at the moment. I’m even more surprised this kind of reactions from open-source developers, as open-source is often associated with increased security by the IT community.

Beyond FileZilla, the bottom line is that passwords require to be stored safely and in a way that even if the file where they are stored is opened or copied, they can’t be read by illegitimate people. KeePass is one of these tools which supports an Auto-Type feature which is smart enough to type the good passwords in the good fields, with anti-keylogger mechanisms, while securely storing your passwords in a AES-256 encrypted database, which then requires a master password to be opened or used. This way, you don’t have to worry about how the passwords get stored by the different software and still somehow get the advantages of storing the passwords in profiles for easy and quick logons without needing to retype your completely randomly generated 64 characters password. There are obviously some security implications with master-password solutions (the stored passwords are only as secure as the master password), but that’s a different story… for another day…