Filter by Category

SFTP vs. FTPS: What's the Best Protocol for Secure FTP?

SFTP versus FTPS apples to oranges comparisonWant newer details on SFTP and FTPS? Check out our 2018 SFTP vs. FTPS article!
An increasing number of organizations are looking to move away from transferring data with FTP (a standard file transfer protocol). In the beginning stages of research, questions often arise around which secure transfer protocols are recommended and how those protocols differ from each other.

Today's Secure FTP Protocols

There are two mainstream protocols available for secure FTP:

SFTP (FTP over SSH) and FTPS (FTP over SSL)

Because SFTP and FTPS implement strong algorithms like AES and Triple DES to encrypt any data transferred, they both offer a high level of protection. SFTP and FTPS also support a wide variety of functionality with a broad command set for transferring and working with files.

Depending on your organization's needs, either option could work to secure your file transfers. However, there are a few notable diffferences between the two in how connections are authenticated and managed.

See how SFTP and FTPS stack up in this free checklist.

Download the PDF 

SFTP vs. FTPS: Authentication

With SFTP, a connection can be authenticated using a couple different techniques:

1. For basic authentication, you or your trading partner may just require a user ID and password to connect to the SFTP server.

Its important to note that any user IDs and passwords supplied over the SFTP connection will be encrypted (this is a big advantage over standard FTP).

2. SSH keys can also be used to authenticate SFTP connections in addition to, or instead of, passwords.

With key-based authentication, you will need to generate a SSH private key and public key beforehand. If you want to connect to a trading partner's SFTP server, you would then send your SSH public key to them so they can load onto their server and associate with your account. Then, once you've connected to their SFTP server, your client software will transmit your public key to the server for authentication. If the keys match, along with any username/password supplied, the authentication will succeed.

With FTPS, a connection is authenticated using a user ID, password, and certificate:

Like SFTP, the usernames and passwords for FTPS connections are encrypted.

When connecting to a trading partner's FTPS server, your FTPS client will first check if the server's certificate is trusted. The certificate is considered trusted if either the certificate was signed off by a known certificate authority (CA), like Verisign, or if the certificate was self-signed by your partner. For self-signed certificates to verify, you must have a copy of their public certificate in your trusted key store.

Your partner may also require that you supply a certificate when you connect to them. Your certificate may be signed by a third-party CA or your partner may allow you to self-sign your certificate, as long as you send them the public portion of your certificate to load into their trusted key store.

RELATED READING: 10 Essential Tips for Securing FTP and SFTP Servers

SFTP vs. FTPS: Implementation

When it comes to ease of implementing SFTP or FTPS, SFTP is considered the easiest secure FTP protocol to implement. SFTP is very firewall friendly, needing a single port number (default of 22) to to be opened through the firewall. This single port will be used for all SFTP communications, including the initial authentication, any commands issued, and any data transferred.

FTPS, unfortunately, can be very difficult to patch through a tightly-secured firewall. FTPS uses multiple port numbers. The initial port number (default of 21) is used for authentication and passing any commands. However, every time a file transfer request (e.g. get or put) or directory listing request is made, another port number needs to be opened. You and your trading partners will therefore have to open a range of ports in your firewalls to allow for FTPS connections, which can put your network at risk and weaken your cybersecurity defenses.

In summary, SFTP and FTPS are both secure FTP protocols with strong authentication options. Since SFTP is much easier to port through firewalls, however, we believe SFTP is the clear winner between the two.

An MFT Solution that Expertly Meets Your Needs

Are you making the switch from FTP? Protect your file transfer communications with managed file transfer (MFT). GoAnywhere MFT can help you achieve automatic encryption, streamline your file transfer processes, and safeguard traditional SFTP and FTPS data transmissions. With support for multiple platforms, including Microsoft Azure, Microsoft Windows, and Linux, you can create a secure, audited environment on any OS for transferring files inside and outside your organization. 

See How GoAnywhere MFT can Improve Your File Transfers

Learn the ropes of MFT in this short, on-demand product demonstration:

Take a Feature Tour


Comments (12)

  1. Brian Buchholtz:
    Nov 01, 2011 at 09:32 AM

    Personally, I believe that the use of any secure FTP is a step in the right direction. I've been out in the field, and you'd be surprised how much sensitive data is still being transacted in the clear. However, if I were to have a choice over which secure FTP technology were to be leveraged, then I'd choose SFTP. The firewall concern is a big deal, especially for a busy server, with lots of concurrent connections. It's not uncommon that an FTP server, which supports passive mode connections, needs open inbound port ranges in the 100's, sometimes even the 1000's. These are ports that an organization has to open to the internet and monitor for abuse. But, most network engineers already know to cringe about this aspect of passive mode FTP. However, there's another side to the firewall story: the clients. I've been finding that an increasing amount of organizations are blocking outbound as well, on the firewall. Passive mode ports (which lack an allocation standard) must be defined as permissible destination ports. Another big network headache. In terms of encryption and authentication, SFTP supports key-based authentication and fingerprinting; whereas, FTPS does not. And, in my honest opinion, I've yet to see any significant, practical advantages a CA-signed cert has over self-signed, in the area of FTP. For instance, FTPS clients can store host SSL certs as approved key material.

    1. Bob Luebbe:
      Nov 02, 2011 at 08:51 AM

      Good points Brian. Thanks for your feedback.

  2. Vince Ponko:
    Feb 12, 2012 at 09:59 AM

    I really wanted to comment on FTPS and SFTP. I always get the two confused. So if I have done that here, I apologize in advance. Here I use FTPS to refer to the extensions of FTP that use the SSL/TLS protocol and its authentication mecganisms. I use SFTP to refer to the SSH-pased protocol that uses SSH authentication. It seems to me that a case can be made that the different models of trust and key management underlying the two protocols are actually one of the most significant and useful differences between them. And that these differences can actually be leveraged to build a complex system with some interesting properties. I know the models of trust and authentication were discussed above, but I will repeate some of that information here because that is the focus of my comments and I want to highlight some things about them. Most of the discussions I have seen about the differences between FTPS and SFTP focus on administration and firewall navigation. Classic FTP is not very firewall-friendly, as it were, because of the need to open two ports per session and the need in one of the more efficient permutations, to open one of the ports inbound. These are naturally also concerns for FTPS because it is an extension of FTP. SSH, and consequently SFTP, only needs one outbound port as I understand it. WHat FTPS brings to FTP, however, is a hierarchical model of trust and public key management based on X.509 certificates and certificate authorities. SSH has a direct model of trust based on direct comparisons of key copies in local repositories and key management based on out-of-band direct distribution of public keys. Note that self-signed certificates can be used in FTPS. This is common in actual business practice although In my opinion it technically violates standard up to TLS 1.0. There may be an acknowledgement of it in newer versions of TLS. I haven't checked recently and it is not necessary for these comments. The point about self-signed certificates that I want to make here is that you they are essentially functionally the same in terms of trust model as SSH keys. They have to be exchanged out-of-band for obvious reasons and authentication of the information in them performed by direct comparison with a local copy, again for obvious reasons. I think it can be argued that direct trust is in some ways unwieldy, especially on a large scale, because of the need to keep up to date local copies of public keys and, in the case of SSH keys, to manually associate them with remote systems. These were some of the problems that CA trust was invented to address. With CA trust, you do not need to maintain local copies of server certificates. You just need to maintain secure local copies of issuing certificates. If you trust the issuing certificates, you can trust the information in server certificates. You can rely on the CA to maintain information about revocation of server certificates instead of having to modify a local database if a key is compromised. Even more interestingly, in my opinion, you can use CA trust and client authentication to build closed trading partner networks where access can can be administred centrally and independently of the databases on the server systems if you want to maintain a private CA. You simply issue client certificates to those you want to allow on your network and revoke them when you want to shut off access. The CA and its signing certificates can be located deep within a secure enterprise infrastructure protected by physical and procedural controls and administered by separate individuals from network servers used for communication. You just have to be able to publish CRLs or run an OCSP responder somewhere the communication servers can get to it. The idea of a hybrid model is that if you are using the system to transmit business documents or messages that contain all the information needed by business systems for processing (for instance EDI) you could consider putting FTPS servers in a DMZ area and using CA trust to control access to them by trading partners, perhaps in conjunction with firewall access rules. If the business documents have all the information needed for further processing, you do not need to propagate any meta-data from the communication servers further. If that is the case, you could find a way to aggregate inbound business documents into one or a few directories. Then you could consider putting SFTP servers that can access the machines with those directories inside the DMZ and only opening outbound firewall ports to them. Because you would be administering potentially only a few SFTP servers and clients, you would not have issues with managing large numbers of direct trust relationships. These are just some thoughts about these prococols based on my experience with them. I did not do any detailed specific research for these comments. They are presented here merely as ideas for discussion. They may be entirely misguided. Use them at your own risk and at your own discression. Any security architecture should have a detailed evaluation by competent, preferably outside, experts before being implemented by an organization.

  3. Bob Luebbe:
    Feb 16, 2012 at 10:34 AM

    Thanks for your detailed feedback Vince. I like your points on how CA trust can simplify FTPS authentication.

  4. Hacking and File Transfers: What You Need to Know:
    Dec 04, 2012 at 09:35 AM

    [...] at the firewall. Then, for permitted file transfers, allow only secure encryption protocols such as SFTP, FTPS, HTTPS, PGP, or GPG for file exchanges in and out of the network. These security restrictions will [...]

  5. FTP Hacking – What you need to know. | Managed FTP:
    Jan 17, 2013 at 01:48 PM

    [...] at the firewall. Then, for permitted file transfers, allow only secure encryption protocols such as SFTP, FTPS, HTTPS, PGP, or GPG for file exchanges in and out of the network. These security restrictions will [...]

  6. Oscar:
    Aug 11, 2013 at 07:20 PM

    By the way... SFTP is not FTP over SSH. Its has nothing to do with FTP or FTPS. SFTP goes under RFC 4253.

    1. Bob Luebbe:
      Aug 20, 2013 at 08:16 AM

      Its true that SFTP is a different RFC standard, however it does provide many of the same command line capabilities of FTP such as get, put, etc. so many just refer to it as as FTP over SSH. FTP has been such a popular approach for transferring files over the last few decades, that it often seen as synonymous with file transfers.

  7. Secured FTP - SFTP Vs. FTPS | Java CodeBook:
    Oct 31, 2013 at 07:35 AM

    […] […]

  8. Joshua Pettus:
    May 06, 2017 at 02:18 PM

    Those are some great points Vince about the advantages of CA certificates. But still, having to open a range of ports really makes FTPS a no go. Do I worry about the third lock on the back door when the front door is wide open?

  9. Steve:
    May 18, 2017 at 03:18 PM

    We are a small company and are doing an increasing amount of secure file transfer. We host our server on Lunarpages. When I asked them about setting up SFTP they said that SFTP requires root access for every user and recommended against it for transferring data between organizations. They recommended using FTPS and suggested that when most people say "SFTP" they really mean "FTPS". We have been led to believe that SFTP is not practical for sending and receiving files between organizations.

    Any comments?

  10. Josh Pettus:
    Oct 04, 2017 at 03:29 AM

    Whoever said SFTP requires root access for all users really doesn't know much about how to setup an SFTP server or the many many features of SSH...I used special accounts that are "jailed" to their home directory that have no further access.

Add a Comment

Allowed tags: <b><i><br>

Related Posts

10 Essential Tips for Securing FTP and SFTP Servers

Most organizations use FTP or SFTP servers to exchange files and other critical business documents with their trading partners. Unfortunately, these servers have become a primary target for hackers,…

Are Your FTP Credentials Secure?

Do you know where your FTP credentials are? A security researcher named Chris Larson happened onto a curious website last September that had been serving some malicious-looking exe files. While…

Data Breach and Incident Response Plans | 2017 Templates & Resources

As we continue to put our data online, through social media channels, cloud storage, and email attachments, we open ourselves up to the possibility of data breaches and other attacks. The answer to…

The Ultimate Guide to Investing in Secure File Transfer Software

It comes as no surprise—file transfers are a critical part of each organization’s operations. They can share anywhere from dozens to hundreds of thousands of documents with trading…

WinSCP Free SFTP Client or an MFT SFTP Client?

If you’re looking for a SFTP client to use for your organization’s file transfers, it might be tempting to go with one that’s free—and bonus points if it’s open source.…