No. Fastest completion time ever OR maybe we need to go into more detail? Okay, to explain my conclusion, I need to go back to the origins of both protocols.
Long long ago, when men were men and laptops were difficult to carry (in the 1980s), BSD Unix introduced RCP (remote copy program). Useful at that time, but with poor security and functionality, it was superseded by the secure copy protocol (SCP), which incorporated the SecureShell (SSH) protocol. SSH allows secure remote login and communication between computers or servers using authentication keys and logins. Traffic using SSH is encrypted by algorithms such as the Advanced Encryption Standard (AES) or the Standard Hashing Algorithms (SHA-2). SSH became an internet standard.
SecureShell File Transfer Protocol (SFTP), as the name implies, was developed from SecureShell and incorporated all of its features. Please also note that SFTP should not be confused with FTPS which is an enterly different protocol that uses Secure Socket Layer (SSL), as opposed to SSH.
Related Article: File Transfer Protocol (FTP) Vs. Managed File Transfer (MFT)
An initial evaluation of SFTP and SCP would indicate that both protocols are equally secure as both use SecureShell as the encryption platform for data in transit.
In 2019, this was not the case (assuming all SCP clients are not patched at this point). ZDNet reported that all SCP use cases since 1983 were impacted by four major security flaws. The flaws were discovered by an F-Secure researcher and all had their origins in the original BSD implementation of the RCP implementation mentioned earlier.
Note that these Man-In-the Middle (MITM) attacks and vulnerabilities are only exploited by taking over an SCP server. Clients that use SCP as the default file transfer methods were all affected and included OpenSSH, Putty, and WinSCP. A user could accept the wrong host fingerprint to allow malicious activity—and user error never happens, right?
However, SCP2 was introduced to fix this issue, so make sure you are using SCP2 and not the obsolete original SCP.
About SCP
In layman’s terms (and I’m not a developer, so I include myself here), SCP sits on top of SSH, but SFTP is developed from it, making it more secure by nature, in my opinion.
Progress’ own WS_FTP Server supports SCP2, since the original SCP, as noted before, has vulnerabilities. In addition, if you want to use SCP, you must use an SCP client, with Putty the recommended choice.
SCP is more suited to Linux environments, but how many enterprises are predominantly Linux-based? It doesn’t matter that SCP clients for Windows are available when SFTP is the dominant standard, not requiring additional clients or scripts to integrate with enterprise-level FTP and MFP solutions.
To me, it’s the same as purchasing Microsoft Word and then realizing other solutions are better for your needs. For example, it doesn’t integrate with or have the same features as Final Draft (industry standard for film scripts) or Scrivener (a popular novel-writing solution). If you don’t need SCP for a specific purpose, use SFTP.
SFTP vs. SCP
While researching this article in the ongoing “SCP vs. SFTP” debate, other issues are apparent. Most experts say that security is the same for both, given that SSH is used by both. Both offer the ability to transfer files, and SCP does so faster than SFTP for high latency networks, as it doesn’t authenticate every packet, using its own transfer algorithm.
The only real pro for SCP – the speed of transfer. However, SCP does little more than its name suggests. It transfers files.
SFTP also transfers files but allows remote file management, directory management, file deletion, renaming, and everything else you’d expect in an FTP solution. In terms of user annoyance, few things are more frustrating than interrupted downloads or uploads. With SFTP, you can resume interrupted transfers. With SCP, you can overwrite a partial transfer or start a new one.
As you can see, there are several pros of using SFTP vs. SCP.
File Size Is Not a Protocol Issue
File size seems a concern for many users, whether it's SCP or SFTP. But, neither protocol has defined size limits. This has nothing to do with security, but it's still worth including—size limits come into play because of restrictions at either the source or destination. Causes of these limits include but are not limited to:
1. Use of Free Services
Providers of free services will place limits on users. Some are manageable, and others are to encourage the user to upgrade to a paid service. These include free server storage, web hosting and more.
2. Use of Paid Services
Even here, there are levels or tiers, and default limits are often imposed. Some are configurable; others require an upgrade.
3. Resource Management
Server administrators set limits according to the number of users and available resources. In some cases, the destination storage may not have enough space.
4. 32-bit Barrier
If the source or destination is 32-bit, the maximum single file size allowed is 4Gb, i.e. large file support (LFS) is not possible. Install a 32-bit client, the same rule applies. Dealing with 32-bit containers? – ditto.
Therefore, if you have issues with transferring files of a specific size or have identified a file size limit, carry out an investigation to find the cause – it’s not the protocol choice that’s the problem here.
Conclusion
Ultimately, in the head-to-head between SCP and SFTP, it all comes down to a matter of choice. What do you need? If you want features, then SFTP is a clear winner. If you wish to transfer files securely, SCP can do it too. If you want security, then both are options.
What’s your take on the SCP vs. SFTP debate? Drop your hot takes in the comments below.
