What’s the Difference? FTP, SFTP, and FTP/S

You have likely heard of File Transfer Protocol (FTP), File Transfer Protocol over Secure Sockets Layers (FTP/S), and Secure File Transfer Protocol over SSH (SFTP), but did you know that there are some major differences among them? Generally speaking, FTP in its basic form is not secure, FTP/S takes the security up a step in that it allows you to secure all or part of a session (at the cost of speed), and the SFTP protocol is used to ensure that all file transmission will be secure and efficient.


FTP (File Transfer Protocol)

FTP is a very well-established protocol, developed in the 1970s to allow two computers to transfer data over the internet. One computer acts as the server to store information and the other acts as the client to send or request files from the server. The FTP protocol typically uses port 21 as its main means of communication. An FTP server will listen for client connections on port 21.


FTP clients will then connect to the FTP server on port 21 and initiate a conversation. This main connection is called the Control Connection or Command Connection. The FTP client will usually authenticate itself with the FTP server by sending over a username and a password. After authentication, the client and server will typically, through a series of synchronized commands controlled by the Command Connection, negotiate a new common port called the Data Connection over which the file will be transferred. The Control Connection remains idle until the end of this exchange, when it reports that the file transfer has either failed or was completed successfully. The conversation between client and server is performed in plain text—all communication between the two parties is sent unprotected, verbatim, over the internet. This makes FTP very unsecure; it would not be terribly difficult for a third party, such as a Man-in-the-Middle Attacker (MITMA), to steal users’ credentials.

There’s an exception to this rule called One Time Password (OTP), in which the server sends a series of digits to the client server in response to the receipt of the USER command. The client grabs those digits and, using a pre-known algorithm such as ROT13 or MD5, the client will generate a hash of their password along with the series of digits to produce a unique password (used one time, hence the OTP). The client presents this hash to the server, which takes the user’s password, already stored on the server, and uses the same digits. If the hashes of the password match, they are authenticated. This is somewhat more secure because the user’s password does not go over the wire– only a hash of the user’s password– so a MITMA usually can’t reverse engineer the password from the hash.


The need for a Data Connection, and its inherent security loopholes, is a major concern in internet usage today. FTP traditionally requires a block of ports to remain open on either the server firewall or the client firewall to aid with the creation of Data Connections. For security reasons, companies are limiting the number of ports in their publicly facing firewalls and looking for alternate solutions in order to keep ports closed and information secure.


FTP/S (File Transfer Protocol over Secure Sockets Layers)

Along with file transfers, clients will typically request directory information from the server. The format of information in directories is often primitive by today’s standards, and as such, the FTP client is sometimes only able to retrieve a subset of the attributes or properties of files available on the server (for instance, the date the file was last modified, but not the date of the file’s creation).


While generic FTP is not secure, extensions have been added over the years to allow for the securing of FTP conversations—namely, the industry standard 2048 bit Transport Layer Security (TLS), the most upgraded version of the old 1024 bit standard SSL. FTP over SSL (FTP/S, as it’s commonly known) allows for the encryption of both the Control and Data Connections either concurrently or independently. This is important because the negotiation of the SSL connection is time-consuming, and having to do it twice—once for the Data Connection and once for the Control Connection—can be expensive if a client plans to transfer a large number of small files.


FTP/S commonly runs on port 990 and sometimes on port 21, the primary difference being that port 990 is an Implicit FTP/S, and port 21 is an Explicit FTP/S. If a client connects to an FTP/S server on port 990, the assumption is that the client intends to perform SSL. Therefore, the SSL handshake takes place immediately; it is referred to as Implicit because the port number implies security.  FTP clients who connect on port 21 and intend to use SSL for security will need to take the extra step to explicitly state their intentions by sending an AUTH SSL or AUTH TLS command to the server. Once the server receives this command, the two parties perform an SSL handshake and enter a secure state—hence why port 21 is referred to as Explicit. This allows the client the opportunity to activate greater security when necessary, or speed the process up on less security-sensitive file transfers.


SFTP (Secure File Transfer Protocol)

SFTP (Secure File Transfer Protocol) is a relatively new protocol developed in the 1990s, which allows for the transfer of files and other data over a connection that has previously been secured using the Secure Shell (SSH) protocol.  While similar to FTP/S in that both protocols communicate over a secure connection, that’s basically where the similarities end.


Unlike FTP, the SFTP protocol is packet-based instead of text-based. Where FTP might send a command such as “DELE file.txt,” SFTP would send a binary 0xBC and then “file.txt.” The key difference is that by sending less data, the SFTP protocol is faster over the long-term as less data is crossing the wire.


Another difference is that with SFTP, file transfers are performed in-line over the main Control Connection, thus eliminating the need to open a separate Data Connection for transfers. This has many benefits. First, by re-using the main connection, no other connections are opened between the client and the server, resulting in a single secure, efficient connection through firewalls.


Since SFTP runs over SSH, it is inherently secure. There is no non-secure version—the encryption cannot be triggered or turned off using AUTH commands, as in FTP/S. This is a plus for system administrators who are trying to enforce corporate security policies.


Another difference is that most versions of SFTP are able to deliver a much richer and more detailed set of data about the files, such as the permissions, date, time, size, and other information not normally available to FTP, thanks to the more robust request protocol of the SFTP.


These are the inherent differences in FTP, FTP/S, and SFTP. WebDrive, which is often used as an FTP client, also supports SFTP, FTP/S and other protocols. Titan FTP Server Enterprise Edition supports both FTP and SFTP, and Cornerstone MFT adds significant security features beyond simply securing the file transfer.

29 comments on “What’s the Difference? FTP, SFTP, and FTP/S

  1. Waqas Rabbani

    Great article

  2. Tim

    So how do we know what we’re using? I’m logging in with WinSCP Client using what says is SFTP on Port 22, but when I attempt to log in using another FTP client, I can’t using the same log in configuration. It’s telling me it’s not secure.

    1. Kim Post author

      Hi Tim,

      The issue here is likely that the “other client” does not recognize the host key associated with the SFTP connection. It would then be considered to be insecure. WinSCP either recognizes the host key, or does not care whether it recognizes the host key.

      WebDrive can do SFTP connections, and can allow you to accept the host key (or you can create your own host key from within WebDrive).

  3. Steve Maughan

    Thank you, this information was exactly what I needed!

  4. Ajith Kumar s

    very helpful

  5. Ganesh

    It is very useful information.

  6. Al

    that was a great post….thanks!…Al

  7. Marcelo Correia

    Very good article, thank you!

  8. Tony

    Good Article!

    I’m trying to connect an older network camera that uses ftp protocol to connect to an sftp server, which seems to be causing errors. Will the ftp protocol always be rejected by a sftp server or is there a way to use the ftp protocol with an sftp server?

    1. Kim Post author

      Hi Tony,

      The SFTP server may also support FTP connections, but you must connect to the server using a protocol that is supported and enabled on the server. If the server wants only SFTP connections, the FTP connection will always fail.

  9. joe

    Is there any other difference between FTP and SFTP other than security? Is there a file type or file size where FTP is the better option to use?

    1. Kim Post author

      Hi Joe,

      As far as other differences, there are many. SFTP opens only one port instead of needing to open an additional port with FTP (If using Passive, a range of ports must be opened on the server).

      SFTP can provide much more detailed information regarding file types.

      FTP may be a bit faster in a transfer of a small file. Over the long run, SFTP is often the better performance choice because of being packet-based instead of text-based (sends less data).

  10. Brad Burke

    Using SFTP, I understand the file is encrypted while being transmitted. It the file still encrypted while sitting at rest once it gets to the FTP site?

    1. Kim Post author

      This is a great question. SFTP provides encryption while data is in transit. It does not offer encryption while data is at rest.

      A solution like Cornerstone MFT would encrypt data-at-rest. An added benefit is that it also encrypts data on-the-fly, encrypting and writing in a single step, so that unencrypted data is never written to the disk.

  11. Lee

    Thanks for the article, Kim – really useful.

    I wonder if you could clarify something for me?

    I’ve been provided with the IP address, User Name and Password for an ‘SFTP Server’ that will be used as the import/export location between my company and one of our clients. We have historically used FTP, so this is my first experience of SFTP.

    Currently I can’t connect to this from our server using an SFTP command until port 22 is opened up on the firewall. That makes sense, but I *can* connect to it using FTP. Is this a failing in the setup?

    My concern is that we will ultimately place files on that server using SFTP, but other parties could use FTP to retrieve them, and therefore it’s not a true SFTP process…

    I previously thought that it was the ‘server’ that determined whether it was FTP or SFTP, but is it simply the means of connection, really, and therefore the provision of ‘an SFTP server’ is not really the right way to look at it, but more ‘a site that will accept SFTP connections’?

    I hope that makes sense!

    1. Kim Post author

      This is a good question.

      A server can be configured to allow more than one protocol to connect – for example, we connect to Cornerstone using SFTP, WebDAV, or FTP.
      You are correct that Port 22 (by default) would need to be opened in order to connect to the server using SFTP.

      You can close other ports on the firewall directly or by using the server administration to block FTP traffic if you would like (21 and 20 by default). You can also block other types of traffic/port numbers that you would not like to get through as well.

      Hope this helps!

  12. taboo

    Thanks for this article- could you please explain whether an organisation would require a full SFTP server in order to use SFTP- so many free FTP clients claim to support SFTP but there is no explanation as to whether they can send or receive via SFTP, or require the corresponding server to be fully SFTP?
    Thanks in advance

    1. Kim Post author

      Thanks so much for your response!

      Yes, an SFTP server is required for an SFTP client to be able to send/receive via SFTP.

      FTP (File Transfer Protocol) is a protocol that is non encrypted. Typically communication is accomplished via TCP port 21 for a control connection and data connections for transferring files and directories are done via another port.

      FTP/S is (Secure File Transfer Protocol) is essentially FTP but involves SSL/TLS secure connections so that all communications between client and server are encrypted. Generally the first step in establishing a FTP/S connection is doing a SSL handshake and after that is successful, FTP commands are sent between client and server; however, they are not on an encrypted channel that is secure.

      SFTP (SSH File Transfer Protocol) is a protocol that has no relation to FTP mentioned above. It is a SSH-based protocol that is secure. SFTP generally uses TCP port 22 for communications between client and server.

  13. tiboolo

    Thanks for the article.

    ‘FTP traditionally requires a block of ports to remain open on either the server firewall or the client firewall to aid with the creation of Data Connections’

    Does that mean that if you open a range of ports for data, say 6000 to 6100, and allow it on the server side firewall, the client does not need to explicitly allow traffic through these ports? ie as long as port 21 is open, the client will be able to connect and transfer?

    1. Kim Post author

      Glad you liked the article!

      You are correct when using Passive Mode (PASV) on the client-side. Passive mode is (more or less) the expected method for most FTP connections that are still used. WebDrive will make the initial attempt to connect with the server and establish that connection, and then the server will present the available ports for connect, and WebDrive will then use one that is available.

      1. tiboolo

        Thanks for the reply, Kim. Makes sense!

  14. KB

    Thanks, This is really user. I use FTP and SFTP for a while and have no idea the different between the two.

  15. Sudhir

    Pretty Concise. Thanks.

  16. Anthony

    Thank you for the information.
    I found this article very informative.

  17. Mike

    Useful, thanks

  18. kannav

    Thanks for the information

  19. Saj

    Fantastic article

  20. amir

    Thanks alot !


Leave a Reply to Ganesh Cancel reply

Your email address will not be published. Required fields are marked *