13

I have a project to build a system that needs to push files to multiple third-party FTP servers. I have asked these third parties to provide a more secure interface; all have declined. So now I have this problem: I can implement some kind of reversible encryption, maybe in a separate process, all to secure passwords that will ultimately be sent over the wire in plain text. Why bother?

Do you think I could probably achieve better gains by focusing on the security of other areas of the application or is it worth the effort to encrypt this data anyway?

curiousguy
  • 5,028
  • 3
  • 25
  • 27
kojiro
  • 579
  • 4
  • 11
  • Sure it is, if you have data and code on two machines, if they robe your data server, the key is in the app server. This way they would not be able to delete your files on ftp at the same time steal your servers. – Andrew Smith Jul 17 '12 at 17:58
  • 1
    Are the passwords chosen by humans or randomly generated? – Gilles 'SO- stop being evil' Jul 17 '12 at 18:50
  • @Gilles As of now they're chosen by humans. You're probably thinking that those humans may use the same password in other places. If so, that's a really good point. – kojiro Jul 17 '12 at 19:07
  • 1
    Choose another vendor or do it yourself. Using FTP is simply **unacceptable** if you care the least bit about either the confidentiality or integrity of your data. and they are not willing to use secure protocols. Unencrypted FTP was a perfectly fine choice for file transfer in the 1970/1980s and has been outdated since the late 1990s. If these morons still use unencrypted FTP server in 2012, I would not trust their ability to do anything with any competence and would expect many many other headaches from other idiotic decision-making ability. – dr jimbob Jul 18 '12 at 15:06
  • @drjimbob I fully intend to remind them that FTP is insecure at every opportunity, but I can't *choose another vendor*. I called them vendors, but to me they're clients. They're not providing ftp as a service to me, it's something they've been using all along as they interact directly with their human customers. I'm automating stuff for them, but as I said below, even if I refuse to get involved, that won't make them stop using FTP. – kojiro Jul 18 '12 at 17:48

5 Answers5

8

I wouldn't bother to be honest. Most application store their database passwords in plain text, i don't see this as being very different. If you are on a shared host, make sure only your user account has read access to the file. I also strongly recommend using SFTP or FTPS, if you aren't using one of these protocols then you are begging to be hacked.

rook
  • 46,916
  • 10
  • 92
  • 181
  • +1; though you can use plain old FTP with their plaintext passwords if its over a VPN tunnel. Though if its a linux setup since open-ssh comes with SFTP; why bother setting up an FTP daemon when sftp comes for free. – dr jimbob Jul 17 '12 at 22:19
  • 1
    …the point of the question is that *FTP* (not SFTP or FTPS) is the only protocol available to me right now. (Even if I refuse this project entirely, these vendors will still be out there with their FTP servers.) – kojiro Jul 17 '12 at 22:31
  • 1
    @kojiro at least notify them that they are making a very serious mistake. They probably don't understand the very basics of security if they are using something as dangerous as FTP. – rook Jul 17 '12 at 23:42
5

I lean towards "naah, don't bother", though I don't think there's a single clearcut answer. In principle it depends upon what data and resources those passwords grant access to, as well as how tightly secured the machine where you'll be storing them is.

If the passwords will be stored on a machine that is reasonably well-secured, and if the data they grant access to is not super-critical, then I wouldn't bother encrypting them. On the other hand, if the passwords allow access to highly sensitive data, then yes, I would encrypt the passwords, and maybe consider additional protections as well -- but then, in that case, maybe you shouldn't be storing it on third-party FTP servers protected by a cleartext passwords anyway. In most situations, I wouldn't bother encrypting the password.

Suggestion: if you are concerned, consider whether it would be easy to change the passwords regularly via some automated process (e.g., once a week or so).

If you are pushing data from one server to another server, then I don't think the risk of interception of the passwords while in transit is super-high. Sure, it's not a risk you should totally ignore, but eavesdropping on data in those situations is relatively rare. The highest risk for eavesdropping is when you send data over a wireless network, or when you send data over a LAN containing at least one compromised/infected machine. I suspect there's a higher risk of the passwords being stolen while at rest, e.g., because someone penetrates one of the two endpoints or because backups go missing.

D.W.
  • 98,420
  • 30
  • 267
  • 572
4

Leaving aside the HUGE issue of FTP security, and looking at the problem of storing passwords, if you need to decrypt the password (as oposed to simply verifying it against a stored, hashed value) then you quickly run into the problem that someone who can gain access to the data can probably also gain access to the key used to encrypt the password. About the only way around this is to maintain copies of the password encrypted using a unique key for every user (i.e. the users password) which is a PITA to manage (although there are some digital wallet solutions available of the shelf).

There are ways to mitigate the FTP cleartext issue: using a vpn is a very obvious solution, restricting access to specific IP address is much less effective but might still be a viable option if no other choice remains. But neither approach comes close to the benefit os using a secure protocol.

As the others have said, the FTP based solution is insecure, assuming you've observed due dilligence and protected yourself by making this clear, then I would suggest that the only option / responsibility left for you is to design your software so as much as possible of the functionality is independent of the protocol used for sending the files, such that you can add support for other protocols easily at a later date.

symcbean
  • 18,278
  • 39
  • 73
3

There's little benefit to reversible encryption if you have a program automatically decrypting it. If some idiot has read access to the script they probably also can execute it and figure out how to decrypt the password. Sure it may prevent "kid-sister" type attacks, but not prevent any challenge to your average attacker.

Personally, I'd opt for plaintext if they won't let you authenticate based on keys additionally with a firewall restricting access.

However, make sure the passwords you do use are random passwords created for just this specific purpose. E.g., a random-generated 16 symbol password that's different for every machine. Don't ever record a real password/passphrase you use elsewhere and have committed to memory. I'd also keep an copy of the password in an encrypted list that's securely backed up (e.g., keepassx with a db stored on dropbox synced to multiple machines; as well as version controlled backup).

Also as Rook mentioned, make sure you aren't using ordinary FTP on the open internet. Passwords (and all data) are sent in plaintext that anyone can eavesdrop on. Use FTPS (FTP over SSL; similar to HTTPS is HTTP over SSL) or SFTP (FTP style file-transfer using SSH) or have a VPN tunnel. Anything else is unacceptable.

dr jimbob
  • 38,768
  • 8
  • 92
  • 161
3

The FTP password is for authentication on the target FTP servers: the password unlocks access to the storage service of these servers. To a large extent, this is their problem, not yours.

To be more detailed, whenever you send a data file to a server, the overall confidentiality and integrity of the data is partly the responsibility of the server's administrator. You cannot make the data more secure than what the peer is willing to achieve, and, by insisting on FTP with passwords and data sent in the clear, the servers' administrators are demonstrating that they do not care much. The password they give you is a delegation of responsibility: they grant you an access and may require some extra protection measures for that, but if they do not, then it is not your role to unduly insist on the subject. As they say, don't try to be more catholic than the Pope. By raising the issue of the insecurity of FTP, you have fulfilled your duty of warning the unwary; from that point, it is up to them to follow up on the subject.

Practically, you might want to take some steps to avoid leaking the passwords on your side, e.g. read-protecting the configuration file which contains them. This is not really to make the system more secure, but rather to avoid becoming the scapegoat if (when) the system is hacked. You then need to show that your end of the protocol was not the weakest point, and since FTP has no encryption and uses cleartext passwords, that's not hard; encryption on your side would be overkill. Also, if the system on your side must proceed unattended, then this means that whatever encryption is applied on passwords can be reversed automatically by your machine, so any encryption you apply would not, theoretically, be stronger than plain read access restrictions on the configuration files. So my counsel is: don't bother with password encryption, it would give you much complexity than real extra security, and that's not the weakest part of your system anyway.

Of course, you might have to ask yourself whether you really want to push your potentially sensitive data to third-party FTP servers whose administrators have demonstrated, by refusing to switch to a more secure protocol like SFTP, a rather disturbing amount of carelessness with regards to security issues. It all depends on whether the data you want to push is really sensitive or not.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949