1

I am planning to transfer encrypted files over FTP. However my other partner wants to use SFTP instead of FTP for security reasons. However my take is since the files are encrypted we can still go ahead with FTP and the data is safe.

NOTE:- The reason I am not choosing SFTP is my system doesn't support SFTP directly.

Please provide your thoughts on this debate.

11
  • 4
    "However my take is since the files are encrypted we can still go ahead with FTP and the data is safe." Your FTP password is not.
    – ceejayoz
    Aug 31 '15 at 22:27
  • 2
    You don't support SFTP, does the other party support it? can you pull the file(s) from them instead of them pushing them to you? FTP is not safe under any circumstances. Do not use it over the public internet.
    – hookenz
    Aug 31 '15 at 23:14
  • @Matt: Any time you make a universal statement, you're asking for trouble (intentional irony there). FTP is safe under some circumstances, namely public (passwordless) readonly access. Configuring FTP for write access is, as Gene notes in his answer, inviting criminal abuse. But that is a threat to availability of the service, not privacy of the data.
    – Ben Voigt
    Sep 1 '15 at 2:28
  • 1
    There is no debate here. FTP needs to die in a fire.
    – womble
    Sep 1 '15 at 3:32
  • 1
    @BenVoigt - There are better protocols for transferring data. I mean, FTP was good 20 years ago but things have changed dramatically. It's also a pain to set up behind a firewall. Some servers require you to open up lots of ports for read/write access. Weakening your firewall. Not so with SFTP. In any case, the op is wanting to give a user write access to his FTP server. This is just bad any way you look at it. Time you got yourself acquainted with SFTP or other more modern protocols and recognize that FTP shouldn't really be used anymore.
    – hookenz
    Sep 1 '15 at 8:29
7

A few things:

  1. Not only do you need to protect the data being transfered, but access to the system you're transfering to. A standard FTP session will transmit credentials in the clear. If an attacker obtains these credentials they can gain access to the system you're uploading to. This will allow them to access anything on the server that account is permitted to access, encrypted and unencrypted files alike.
  2. Additionally, they'll be able to cause you grief by removing files you upload, upload fake files, or cause other disruptions like filling up the allocated disk space on the FTP server.
  3. And also if an attacker does get ahold of your credentials they can use the FTP server to host and distribute content to their liking. This could be problematic for your associate if they host illegal content.

And lastly, it's not a good idea to assume that your encrypted files are fully protected. Someone sniffing that traffic could store the files to decrypt later as newer and faster decryption methods are released. Can you be certain that the encryption scheme you're using won't ever be exploited?

If the data is important to you encrypt your connections when you can.

5
  • Someone sniffing that traffic could also store the FTPS session capture to decrypt later as newer and faster decryption methods are released. Your case is made by bullet points #2 and #3.
    – Ben Voigt
    Aug 31 '15 at 23:07
  • 1
    It's important to make it as difficult as possible for your attackers. There's no such thing as perfect security, you can only do your best to make it as difficult as it can be.
    – Gene
    Aug 31 '15 at 23:11
  • @BenVoigt Maybe you are right in the case of FTPS. But why would anybody use FTPS when they can use SFTP? When SFTP is being used, the session key is better protected than an encryption key for data at rest ever could be. Once the session is over the key is gone. Even the two endpoints which participated in the communication cannot reconstruct the session key at that point. But by all means for highly sensitive data combine the two.
    – kasperd
    Sep 2 '15 at 8:45
  • @kasperd: But Genie's answer is concerned with the possibility of decryption without foreknowledge of the key. Other parties destroying their copies have absolutely no impact on discovered weaknesses.
    – Ben Voigt
    Sep 2 '15 at 14:33
  • @BenVoigt How did the key get transferred in the first place? It is not at all unlikely that the key was only protected by a password when it was transferred. And even if it wasn't, then that key becomes a weak point as once it leaks, all past communication will be decryptable.
    – kasperd
    Sep 2 '15 at 19:24
2

Taking from another angle. How comfortable are you with someone outside your company having access to those files even if they are encrypted? If you're nervous then rightly so. You don't want to use FTP.

It's not at all safe to use FTP as a transport medium over the internet. FTP should have been phased out years ago. FTP passwords are transmitted in the clear. So an attacker who obtained that password can download your encrypted files directly from the FTP server for themselves and given as much time as they want, could in theory decrypt them.

Also, they could tamper with your files on the ftp server. How will you trust them to be authentic? They might also delete them or upload some rubbish to your FTP server and fill up it's disk with junk. So, can you white-list the server to only those you trust?

So now your security is entirely up to the encryption of the files themselves and whether you can trust them. If you used simple zip encryption, I'd say you could be in trouble. Don't use a simple password based encryption. Consider something like PGP as a better option.

Also, think about the idea of pulling the files from SFTP if the other party has an SFTP server. Or if you can, upgrade your FTP server with SFTP. Also, encrypt your most important archives/applications if required. Especially sensitive material. Because sometimes it's the people within your organization who can be the biggest threat. e.g. people leaving the company.

6
  • Weak encryption is weak, and strong encryption is strong. This is totally irrelevant to the question of whether the encryption is done at the file layer or the transport layer.
    – Ben Voigt
    Aug 31 '15 at 23:05
  • 2
    @BenVoigt - nonsense. If the encryption is strong but the user decided to use a simple password it'll be cracked in no time, and without the concern of round trip time on a network. You haven't considered that.
    – hookenz
    Aug 31 '15 at 23:12
  • Sure, and if your FTPS server private key got leaked as a result of heartbleed, you lose too. You need strong encryption with a strong and well-protected secret. That's possible regardless of what layer implements the encryption. The fact that some file encryption programs use too little entropy is not an argument that file encryption is inadequate, it's an argument not to use those programs.
    – Ben Voigt
    Aug 31 '15 at 23:19
  • I'm talking about using FTP. You seem to be defending it's use. I'm saying, having understood that it's unsafe and your password is in the clear, do you trust relying on the archive encryption alone.
    – hookenz
    Aug 31 '15 at 23:25
  • FTP has its place -- serving files (read only). Same conditions under which you don't need a password. I would rely on the same encryption that I would for a file being sent through email (which is as insecure as FTP, if not more so) -- something like PGP. I don't know why you are talking about zip file passwords, since the question said nothing about them. "encrypted file" does not equal "weak archive password".
    – Ben Voigt
    Sep 1 '15 at 2:25
1

Use FTPS then. The problem you face is more for eye dropping on the data.

If the attacker can uncrypt your file you will face big trouble.

If you really need FTP think to give the user a VPN connection. That would encrypt the transfer.

4
  • I consider SFTP to be a much better choice than FTPS.
    – kasperd
    Sep 2 '15 at 8:48
  • @kasperd yes, but the op told he cant use sftp,and unlike sftp, ftps is available on a lot of ftp product
    – yagmoth555
    Sep 2 '15 at 10:05
  • I have seen a lot more systems with sftp support than systems with ftps support. Moreover AFAIK ftps uses the same two-connection model as ftp, which tends to break as soon as soon as it comes near a NAT or a firewall.
    – kasperd
    Sep 2 '15 at 19:20
  • @kasperd well, my argument was valid for windows OS, your for Linux. As right now for windows only around 5 paid product exist for sftp, while all other support ftps (like filezilla server, iis, etc..). The OP didn't mentioned the OS
    – yagmoth555
    Sep 2 '15 at 19:26
0

If you must use regular FTP, then if all the following conditions are met, you wouldn't be doing that bad in my opinion:

  • Restrict access to the FTP site to only certain trusted IP addresses to prevent hijacking of the FTP account for other purposes
  • Ensure the username and password for the FTP account are not used for anything else and cannot be used to gain access to anything such as via SSH
  • Ensure the type of encryption being used is a good one (such as AES256)
  • Use a very strong encryption key (to prevent brute force attacks)

As a side note, you may be able to forward the unencrypted FTP traffic over an SSH port forward, and then your system can use regular FTP but the connection still be encrypted.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.