Plaintext FTP risks

Classic FTP does not encrypt anything. A person on the network path can read usernames, passwords, commands, filenames, listings, and file contents.

They can also change bytes in flight. Locking down filesystem permissions on the server does not fix that. The traffic itself is exposed.

Here is what cleartext looks like if you capture the session:

USER alice
PASS s3cr3t-pw
CWD payroll
RETR july.csv

The salary rows travel on the data connection in the same readable form. Anyone on the same café Wi-Fi segment could read that capture without special tools.

I still meet teams that say “FTP is fine inside our VPN.” Fine for confidentiality against the internet maybe. Not fine against everyone on the LAN.

Protecting only the password would still leave filenames and file bodies visible. Protecting only the control connection would still leave listings and transfers on the data channel readable.

Cleartext also lacks integrity. An on-path attacker can alter a downloaded installer, replace an upload, or change a reply. A successful 226 proves only what the FTP server saw on that connection, not that nobody tampered on the wire.

When a partner still requires FTP commands, use explicit FTPS with PROT P so data connections are encrypted too:

AUTH TLS
234 AUTH TLS successful
PROT P
200 Data protection set to Private

When you control both ends, SFTP or HTTPS is usually simpler than fighting passive ports in cleartext.

Do not put authenticated cleartext FTP on the public Internet. Lab networks behind a VPN are one thing. The open internet is another.

Write a short table for the transcript above: what a passive observer learns, what an active attacker can change, and what still remains risky after TLS.