Why plain FTP is insecure: plaintext passwords and what to use instead

Plain FTP, the original File Transfer Protocol from RFC 959, with no encryption, still turns up in scripts, legacy appliances, and “it’s just an internal transfer” shortcuts. It shouldn’t. Plain FTP sends everything in cleartext, including the password, and that’s not a configuration mistake you can fix: it’s how the protocol works.

Here’s precisely what’s exposed, and what to use instead.

What “cleartext” actually means here

When a client logs into a plain FTP server, the exchange on the wire looks like this:

USER alice
331 User name okay, need password
PASS s3cr3t-passw0rd
230 User logged in, proceed

That password is sent as-is, unencrypted. So is every byte of every file you upload or download afterward, and every directory listing. Anyone able to observe the network path, a compromised router, a shared Wi-Fi network, a malicious host on the same subnet, an ISP-level tap, can read all of it with an ordinary packet capture. No decryption, no cracking required; it’s already plaintext.

What’s exposed, concretely

• Credentials. The username and password, captured verbatim, instantly reusable.
• File contents. Everything transferred, readable in transit. If you’re moving anything sensitive (PII, financials, keys, customer data), it’s exposed.
• Metadata. Filenames, paths, and directory structure, useful to an attacker even when the files themselves aren’t the target.
• No server authentication. Plain FTP gives the client no cryptographic proof it’s talking to the real server, which opens the door to man-in-the-middle interception.
• No integrity protection. Data can be altered in flight without detection.

”But it’s only on our internal network”

That’s the most common justification, and it’s weaker than it sounds. Internal networks get compromised; laptops roam onto them; a single foothold turns “internal” into “observable.” Cleartext credentials are exactly what an attacker pivots on after an initial breach, one captured FTP password is often reused elsewhere. Defense-in-depth means not shipping passwords in plaintext, even inside the perimeter.

Active vs passive mode doesn’t help

A frequent misunderstanding: switching plain FTP between active and passive mode changes only how the data connection is established (which side opens the port), it does nothing about encryption. Both modes are equally cleartext. The mode setting is about firewalls and NAT, not security.

What to use instead

Use a protocol that encrypts the session. You have two good options:

• SFTP, the SSH File Transfer Protocol. Runs over SSH; credentials and data are encrypted, and it uses a single connection on one port. Simplest to operate in the cloud.
• FTPS, FTP wrapped in TLS. Encrypts the same FTP you already know; useful when a partner or legacy system specifically needs FTP semantics.

Both are secure when configured correctly. The trade-offs between them are covered in SFTP vs FTPS, but the rule above plain FTP is simple: anything but bare, unencrypted FTP.

How this maps to a managed gateway

A modern managed gateway gives you encrypted transfer without standing up servers: per-user credentials (SSH keys or password) carried over an encrypted session, each user path-jailed to their own prefix, and a full audit trail. Firepipe’s endpoints are SFTP, encrypted by design over SSH, in front of a cloud bucket you own. So you can retire a plain-FTP drop-zone for an encrypted one without migrating your data: see SFTP to S3, or, if you’re decoding an error along the way, the FTP and SFTP code reference.

Bottom line

Plain FTP transmits passwords and files in cleartext, readable by anyone on the network path, and no setting fixes that: it’s the protocol’s design. If you’re still running it, the migration is low-risk and overdue: move to SFTP (or FTPS where FTP semantics are required) and stop shipping credentials in the clear.