Our hosting provider only supports using FTP, not sFTP. Is this safe enough? [closed]

standard FTP is completely unencrypted

Standard FTP has supported encryption since as far back as 1997. Whether your provider's FTP server supports it, enforces it, and whether it will be used in your file transfers is another matter.

FTP is one of the earliest internet protocols. RFC 765 that first specified it is from 1980, more than a decade before HTTP that backs the world wide web.

It has evolved quite a bit since to adapt to the evolving face of the internet. Like HTTPS was introduced to add encryption and authentication to HTTP via SSL/TLS, the same was done for FTP with FTPS (RFC 4217¹ from 2005).

Like SMTP (mail transfer), POP3, IMAP (mailbox access), and many other protocols, TLS can also be requested in-band (also referred to as Opportunistic TLS or STARTTLS even if FTP the command in the FTP protocol is AUTH TLS rather than STARTTLS) in the FTP protocol.

So encryption is possible in FTP and can be made as safe as other encrypted protocols.

Now the FTP protocol is a bit clunky as the commands in the protocol and the actual file transfers are done on separate TCP connections. The original default method where it was the server connecting back to the client no longer works well now that most internet machines are behind NAT firewalls (thankfully, most FTP clients these days have changed the default so it's the client that also connected to the server for the data transfers).

Those separate connections complicate the encryption somewhat as keying material must be shared between them, so it's harder to get right and some FTP clients have been known not to. It's also possible to send the commands (including username and password²) encrypted while the data is transmitted in clear, so it's important to configure the FTP client so it requires encryption both for the command connection (either implicit with FTPS on TCP port 990 by default, or with opportunistic encryption, with AUTH TLS on a normal FTP connection (port 21 by default)) and data connections (directory listings are also retrieved on data connections).

Some FTP clients have also been known not to verify server certificates properly which can significantly reduce the confidentiality of the transfer as it allows MiTM to intercept traffic.

So, in short FTP can be secure but

• encryption must be supported by both the client and server software and it must be done correctly.
• users must make sure the clients are configured properly (it's often not just a matter of checking that there's a padlock icon like for HTTPS) to make sure encryption is used.

With the lftp command line client (which supports a wide range of file transfer protocols including SFTP, HTTP(S), FTP(S), DAV, torrent...) for instance, see these configuration settings:

• ssl:verify-certificate (boolean)
  if set to yes, then verify server's certificate to be signed by a known Certificate Authority and not be on Certificate Revocation List. You can specify either host name or certificate fingerprint in the closure.

• ftp:ssl-allow (boolean)
  if true, try to negotiate SSL connection with FTP server for non-anonymous access. Default is true. This and other SSL settings are only avail‐ able if lftp was compiled with an ssl/tls library.

• ftp:ssl-auth (string) the argument for AUTH command, can be one of SSL, TLS, TLS-P, TLS-C. See RFC4217 for explanations. By default TLS or SSL will be used, depending on FEAT reply.

• ftp:ssl-force (boolean)
  if true, refuse to send password in clear when server does not support SSL. Default is false.

• ftp:ssl-protect-data (boolean) if true, request SSL connection for data transfers. This provides privacy and transmission error correction. Was cpu-intensive on old CPUs. Default is true.

• ftp:ssl-protect-list (boolean) if true, request SSL connection for file list transfers. Default is true.

So if using that FTP client, you'll want to add set ftp:ssl-force 1 to your ~/.lftprc and make sure the other ones are not modified from their default to ensure encryption is used. Then if the FTP server doesn't support encryption or doesn't provide a certificate for the host name by which you connect to it issued by one of the certificate authorities that your system trusts or there is a MitM, the connection will fail without you having potentially leaked the credentials.

Note that a FTP server can also be configured to reject client connections that don't use encryption. For opportunistic encryption, that's still vulnerable to a MitM if the client doesn't also require encryption, as while the server will for instance refuse unencrypted authentication, the MitM can accept it (and forward encrypted to the real server to check that's the right password or not and serve malware regardless for instance).

it only takes minutes(seconds?) if you send admin credentials unencrypted over the internet to have your system compromised.

Not necessarily, one still needs to have access to any part of the pipe from the client to the server to be able to sniff that traffic and get access to the FTP user password, so unless you're connected to a dodgy wifi network, that should be mostly limited to network operators and governments or state hackers. Leaking that password will normally not lead to your system being compromised. A MitM could however make you download malware instead of the files you were meant to download. Same could happened with HTTPS if you ignored certificate warnings or SFTP if you did not verify the SSH host key.

SFTP (the SSH File Transfer Protocol) itself is an entirely different protocol that works over an SSH connection, not standard in that its specification has never gone past the draft stage at IETF, but more modern and widely used and fixed many of the shortcomings of FTP. See https://www.sftp.net/sftp-vs-ftps to clear confusions between FTP and SFTP and the other names they may be given.

^{¹ Itself based on RFC2228 from 1997 which specified a framework for providing strong authentication, integrity, and confidentiality on both the control and data channels with the introduction of new optional commands, replies, and file transfer encodings, along with a way to use GSSAPI (RFC1508 1993) as security mechanism; RFC4217 basically specifies TLS as a different security mechanism and AFAIK got much wider support in FTP client and server implementations.}

^{² Not that authentication has to be done with username and password; with TLS, that can also be done with client certificates; and there's a possibly wide range of options with GSSAPI.}

Well, your credentials sent by email should be considered compromised. Change the password at once.

If you use credentials for FTP, they are compromised. Make sure that is all they have access to, and that the server is hardened. As in, if you can, make a second set of credentials just for FTP use... and maybe disable/deleted it just after.

Ideally, use something encrypted and strongly authenticated, like ssh (and sftp and scp) with public/private keys, or rsync over ssh to transfer files. Failing that, fall back to something with encryption and passwords like @ReflectYourCharacter listed.

I would be aware that the server side is the one that will be compromised if something goes wrong, not your system. So you might want to securely encrypt any confidential data you put there. Consider PGP/OpenPGP/GnuPG. If you want it fully readable by others, use the cryptographic signature options, and work out how to securely distribute your public key.

Edit: Also be aware that if the hosting provider is this sloppy with you, they are probably this sloppy with everyone. So you're being careful won't necessarily make any difference to the hosting provider being compromised.

"What should I do?" is a highly subjective question that truthfully only you can answer for yourself. However if I were told what you say you were told by any prospective hosting provider, my response would be to immediately take all of my business elsewhere.

A "hosting" company that only uses FTP to transfer files is akin to a bank that only uses HTTP for its web site rather than HTTPS, and should be viewed, in my opinion, with just as much derision.

According to the ftp protocol, ALL data must be in the clear (unencrypted), your FTP userid and password (which better not be used elsewhere), and all the data you exchange.

That's why any computer security aware being avoids ftp if at all possible.

Login userid AND password in the same E-mail? Change your password AT ONCE.

This "hosting provider" seems stuck in the Computer Security atitude of Internet Virgins of 1978. BTDT. Not Safe! Run Away!