No matter how embedded into our lives cloud computing becomes, there are still plenty of companies and individuals that rely upon good old fashion file transfer protocol (FTP). There's a reason for that. FTP is easy to use, reliable, and can be set up securely.
But we are no longer in the nineties and having to pay for an FTP client shouldn't be necessary. There are plenty of tools available that range in the simple, single-minded FTP application to the feature-rich, more complicated tool. With that in mind, I have found five FTP clients that should fit nearly any situation and do so without costing you or your department a penny.
1. File Zilla
FileZilla is a cross platform client (Windows, Linux, *BSD, Mac OS X, and more) that offers tons of features, such as support for FTP, FTP over SSL/TLS (FTPS), and SSH File Transfer Protocol (SFTP).
Credit: Images by Jack Wallen for TechRepublic
Jack Wallen is an award-winning writer for TechRepublic and Linux.com. He’s an avid promoter of open source and the voice of The Android Expert. For more news about Jack Wallen, visit his website getjackd.net.
Auto FTP Manager is a good free FTP client -http://www.deskshare.com/ftp-client.aspx
How can you review an FTP client and not mention that it has a 2Gb transfer file limit? Otherwise FireFTP works well.
Most of the companies I work with recommend WinSCP for secure data exchange. It is nice and light weighted tool with utilities like PuTTYgen that comes handy when you need to have key generated.
Another Free FTP http://bluezone.rocketsoftware.com/products/secure-ftp
Regarding Filezilla storing passwords in clear text. If you have a legitimate concern about security, you shouldn't be storing passwords in the first place.
There is one more FTP (ans FTPS + SCP) client worth mentioning - WinSCP. It has 2 types of interfaces to choose from - 2 panel or explorer-like. Give it a try: http://winscp.net/eng/index.php
Try using Totalcmd (Total Commander) for FTP as well as a total file managment tool for copying/delet/edit, compress, search and much more http://www.ghisler.com/
Great product but the product stores the passwords in clear text and several hacks have been written that steal those clear text passwords. The developer does not think that storing clear text passwords on an internal network is an issue and as such has refused to offer a solution.
FTP is by definition a clear text environment. Why hack when you can simply read the password on the wire?
In his very first paragraph, he states: "FTP is easy to use, reliable, and can be set up securely." Since he never mentions how FTP can be set up securely, that statement is dangerously misleading at best. FTP is absolutely, positively, in-no-way-what-so-ever secure. SFTP, yes. FTP, hell no. FTP can only be "set up securely" by using something else to encrypt the data within it prior to transmission or by placing FTP traffic within another encrypted protocol (like a VPN tunnel). Using a password on a bare FTP transfer is arguably LESS secure than leaving it open to anonymous access. With anonymous access, it is obvious anyone can grab the file. With a password? FTP passwords are sent in cleartext, allowing any device that can see packets between the client & server to see the password. It may verify you are the FIRST person to know that password, but after you've shown it to everyone on the network it can't be assumed you're the ONLY one who knows it. Worse: even if a password is used, the payload is still unencrypted. Anyone on the network still sees everything. FTP does not support encryption of password or payload. If you want to either, use a modern protocol (SFTP) or put it in a tunnel. Also, despite infosec's best efforts to discourage the practice, humans tend to re-use passwords. A lot. I'd rather there be no illusion of FTP transfers being secure than somebody wrongly believing they're protected by using an FTP password (likely also used to log into their webmail account, etc).
...only the hash values of the passwords. A password is submitted by the user, runs through the hash algorithm, and is compared to the stored hash value. If the two match, access is granted.
Many users don't dig deep enough to know that. They trust that whoever created the program/protocol must've known what they were doing. They see it is configured to use a password, and don't stop to think how it is sending/storing that password (or the data the password is supposedly protecting).
Just not in plain text. Which brings us back to the original problem, that the server is storing passwords in plain text.