Filezilla3 final released

[Ci-Dev]

And, how exactly is the O/S going to take care of protecting the content of a file owned by an application?

I am using Windows XP and if I right-click on any file and choose "properties", there is an option somewhere to encrypt the file. If it is ticked, no other user can access the file. So if I log out and log in back as someone else, I cannot access the file anymore. So only me with my normal user account can access the file. It works for any application and I just need to remember my Windows account data - very easy, very comfortable.

[Feldon]

I'm sorry but your answer just doesn't cut it.

Go back into your cave. If you actually had the technical understanding on how computers work, you would now that password obfuscation is pointless.

What kind of an arrogantly stupid answer is that? What is your understanding of how computers work for one? Come on, spell it out and come up with something else than utterly immature insults to answer a legitimate request. If you're so good do explain why passwords are not obfuscated in FileZilla. Make your case very well because I can guarantee you that you will eventually have to concede that storing password in clear in totaly wrong.

[LINKS TO VARIOUS ARTICLES]

Come back with your reply when you're able to express your point of view like an adult instead of behaving like a total jerk and perhaps then will people respect your position on application development and computer security.

Good luck...

(Staying on topic, and ignoring the abusive tone of some of the posts.)

The on-line articles you mentioned are discussing xml files that can be read by all users. A simple example would be to store an xml file containing cleartext passwords in c:\program files. This is NOT what we are discussing with FileZilla. With FileZilla we are talking about storing xml files in a users home directory. Home directories on modern operating systems are already encrypted or otherwise strongly protected. Therefore, encrypting passwords stored on these home directories would be redundant.

That being said, "security in depth" is generally a good idea. If a hacker managed to break the O/S home directory protection, they would then have to overcome the encrypted password stored in the XML file. However, you must realize that this additional security comes at a cost to the end-user. Either a) you would be unable to recover encrypted passwords (the current situation with FZ2), or b) you would have to remember another password that would be your private key, and this private key would have to be entered every time.

botg has made the decision that these costs are too high compared to the limited security gained through password obfuscation. Hence, no encryption.

My position? As another user mentioned, some users may not find cost b) described above that onerous. Perhaps at a later date, botg should consider adding private key encryption, and requiring the user to enter this private key once per session.

[sr1515]

The solution is so simple: The operating system has to provide a secure storage for the user's files and settings by means of an encrypted home directory which is only accessible while the user is logged in.
At least since Windows 2000 (maybe NT4) this has been implemented, Windows does support file encryption natively.
Encrypted file systems are also available for all other operating systems.

Much better language level. Good. Thanks.

Your approach with application password management has obvious merits but it's not really practical. The majority of users, whether in corporate or home environments, don't encrypt their home directory or partition. Granted, it would be so much better if everybody did but it's not the case. In the meantime, the more obstacles built around sensitive data, the better.

In this context, even if FileZilla implemented a small algorithm to garble passwords before they would be stored in the settings file, it would be enough in most cases to block users with prying eyes from snatching the passwords on a shared computer, which is very often the case. That is one of the reasons most applications rely on some obfuscation or encryption to store user passwords, and especially applications providing networking functions. Like Mozilla does as mentioned before, or for FTP clients, WinSCP, CoreFTP, FTP Commander, etc...

Rest assured that I'm not trying to make this a feature match between your FTP client and other clients. I've been using FileZilla for years and I think it's an excellent client. However, please do reconsider how you manage passwords within your application. Sure, any algorithm you would implement to scramble passwords would be right there in your GPL code but grafting such a password protection function to FileZilla (optional or not it doesn't matter) would be much better than having no user passwords protection at all.

On a final note, perhaps others will wish to submit their views and contribute to your reflexion on the subject but, whatever happens, please try to keep from uselessly bashing people who just try to contribute to your efforts at making your application stand out as the best. Thanks and best regards.

[spucek]

If i could write that kind of English, i would write post above me. Basic protection with simple algorithm is much better that no protection at all. If Tim agrees is another story :p .

[botg]

Basically security is a binary issue, either something is secure or not. If the system isn't secure in the first place, adding another layer of security is futile. Try multiplying a zero with some other number, the result is always the same.

[sr1515]

Basically security is a binary issue, either something is secure or not. If the system isn't secure in the first place, adding another layer of security is futile. Try multiplying a zero with some other number, the result is always the same.

Again, not practical considering that the vast majority of users do not use encryption on their home folder or partition. You're entitled to your views though. It's your application. Nevertheless, purist solutions aren't necessarily the best, especially in security.

[ddcc]

Although switching to another operating system would be nice, most users would refuse to switch from Windows to Linux or to Macintosh.
When a file-stealer is, say, set to run in the Local Machien hive of the registry and when the user who encrypted the file logs in, isn't the encryption useless?

[botg]

Which raises the question how the file-stealer got there in the first place. If the system isn't secure, everything else is futile. If the system is secure, application based password encryption is useless since the system is secure.

[boco]

As for the home folder protection, please remember most of the casual users have Windows XP Home, where NTFS encryption and easy permission management are not available.

[botg]

As for the home folder protection, please remember most of the casual users have Windows XP Home, where NTFS encryption and easy permission management are not available.

Not my job to work around problems in crippleware.

[sr1515]

As for the home folder protection, please remember most of the casual users have Windows XP Home, where NTFS encryption and easy permission management are not available.

Not my job to work around problems in crippleware.

Guess you're a *nix fan. Me too. Slackware is my primary O/S.

So considering your position on not obfuscating/encrypting passwords in FileZilla's sitemanager.xml, why do you explain that passwords in /etc/shadow are encrypted on a *nix based O/S? As for applications, I have yet to find one Linux/*nix application that doesn't obfuscate or encrypt passwords entrusted to it, whether these would be local or remote passwords.

Again, you're entitled to your position on avoiding to garble passwords in FileZilla, but I would like to see what is your source reference on that policy, apart from your personal opinion that obfuscating passwords is useless. Can you quote any security firm or expert out there who thinks like you do about that matter?

[eddan]

So considering your position on not obfuscating/encrypting passwords in FileZilla's sitemanager.xml, why do you explain that passwords in /etc/shadow are encrypted on a *nix based O/S?

We just need to make clear here that FileZilla will need a two-way-encryption/decryption algorythm, as it needs to pass the actual password to the ftp server it connects to. A one-way one that AFAIK is used for /etc/shadow is a lot easier to do, especially for an open source program since the code to do the two-way encryption/decryption would have to be made available for everyone to see.

Having said that, I'm voting for some obfuscation, as at least that would prevent an (extremely tiny) bit more effort from the hacker/cracker. I admit, it's not secure and it's a false one, but it might scare a newbie hacker away.

[sr1515]

So considering your position on not obfuscating/encrypting passwords in FileZilla's sitemanager.xml, why do you explain that passwords in /etc/shadow are encrypted on a *nix based O/S?

We just need to make clear here that FileZilla will need a two-way-encryption/decryption algorythm, as it needs to pass the actual password to the ftp server it connects to. A one-way one that AFAIK is used for /etc/shadow is a lot easier to do, especially for an open source program since the code to do the two-way encryption/decryption would have to be made available for everyone to see..

That's not what I was refering to. I was refering to no obfuscation of passwords in the sitemanager.xml file used by FileZilla. The way I view it, anyone who needs an encrypted FTP connection just needs to use sFTP.

Having said that, I'm voting for some obfuscation, as at least that would prevent an (extremely tiny) bit more effort from the hacker/cracker. I admit, it's not secure and it's a false one, but it might scare a newbie hacker away

Passwords shouldn't be stored anywhere in readable form. As for the way they are transmitted over networks, it's a matter of protocol more than anything else.

[botg]

Passwords shouldn't be stored anywhere in readable form.

Define readable. Obfuscation does in no way protect against attacks.

[sr1515]

Passwords shouldn't be stored anywhere in readable form.

Define readable. Obfuscation does in no way protect against attacks.

Readily readable, human readable. Any obfuscation/encryption of locally stored passwords related to remote sites will at least rise a barrier forcing anyone who obtains physical or remote access to the local machine to work his way through that much more obtacles if he wants to obtain the garbled information. As I wrote earlier, I have yet to see any application on *nix that stores any type of password in human readable form. Never saw much of those on Windows as well. Passwords stored on disk should always be garbled somehow making them harder to snatch by prying eyes.

I have problems with an application that provides the capacity to establish SSL connections with a client and that at the same time allows passwords associated with those remote SSL connections to be stored in clear form on the local disk. Anyway, I think I made my point clear on this matter and I'm not going to pursue this any further. To me this topic is a matter of basic security over anything else.