I could make fun, except in 2018, I moved a company off of FTP and onto S3. To be fair to the company, no developer had worked there since 2016, so they were just running on autopilot. Still, anyone even vaguely concerned with security should have stopped using FTP since sometime in the early 00s.
See for example https://security.stackexchange.com/a/115565 or https://en.wikipedia.org/wiki/FTPS#Secure_data_channel for more detailed explanations.
Most of the time both are encrypted when configuring TLS, but it's not as easy as with IMAP or SMTP where you basically disallow all commands except STARTTLS.
Had the same discussion in 2018.
But if the weak link in the chain is "our (paying) customer is so tech illiterate that they need a printed out tutorial to use an FTP client, and switching to SFTP would anger all clients", what are you going to do.
In another case around 2015, a coworker started and was learning the system. He found that a web store front was being powered by an FTP box that had a list of items in it, and the FTP box was periodically being updated by someone somewhere, but he couldn't figure out who or where. As far as I know, he never figured it out, and the mystery uploads continue to this day…
I'm sure there were hundreds of decisions by dozens SolarWinds managers like this that worked out fine. They made some personally and immediately beneficial choice and got praised for getting things done on time and on budget. The latent problem, be it a security risk, a hidden pile of technical debt, or a cut corner, stayed latent.
Unless you can rejig the system to change the odds for those individual decision-makers, things like this will keep happening.
I think you are vastly overestimating the capabilities of the users.
They are the sort of person who has been using the same version of FileZilla since 1998 to do their weekly file upload of stock data.
To them, nothing could ever be easier.
Also, I would not be the engineer to want to write a client app in 2020 with Windows XP / IE6 compatibility.
I'd have some flag so that new customers can't use something insecure.
If my service was used for private data, I'd force old customers to migrate. If not, I would advise them via a service bulletin, but let them carry on with their insecure setup.
I understand that in the world of business, security risks are like any other risk, and a dollar value can be put on every security improvement, and sometimes that dollar value isn't good value for money.
It's astounding how big a problem sharing files that are too big for email still is.
The safe, secure and completely free way to transfer large files around the Web.
What is ZendTo?
It is a classic problem: you need to send files to someone, or they need to send them to you, and there's no way except email. But they are too large or your administrator won't let you transfer the files by email at all. ZendTo to the rescue!
Why ZendTo?
ZendTo is a completely free web-based system, which you can run on your own server with complete safety and security. It runs from any Linux / Unix server or virtualisation system, there is no size limit and it will send files 50% faster than by email.
This was easy for the customer to upload their .csv onto (at their own convenience, and their own schedule).
How would you set up this push-based flow?
The issue here was that their update pipeline was compromised and they were distributing compromised updates.
Stop kneeling at the altar of PKI.
The reasons for moving away from FTP is because it’s unergonomic and the software support isn’t there anymore, not just because it’s old. And if you use IIS on Windows you’re pretty much stuck with FTPS.
The idea that FTPS is bad and you should feel bad is more like the JSON vs XML debate than it is legitimate security gripes.
good old FTP