On Fri, 10 Jan 2003, Ed Wilts wrote: > I still stand by my claim that ftp is more secure than sftp... > > .../Ed
I'll make you a bet, I will bet you $500 if: 1) You go to the center of the Def Con Eleven "Capture the Flag" room on August 1st at noon 2) Yell out three times "I stand by my claim that ftp is more secure than sftp" (afterward I will start laughing for at least 60 seconds) 3) Pick me out from everyone else that is laughing Even script kitties recognize FTP as having much more serious problems than sftp. SFTP does *NOT* have any of the following problems that FTP implimentations have been known for: - FTP bounce attack (nmap option "-b") to use an ftp server as a proxy for network scanning. - Unencrypted authentication - re-usable authentication tokens is still common practice. It is rare to find people using OTP (One Time Passwords), SRP, SASL or Kerb in connection with FTP to address this issue. - Masquerade attack - along the same lines as unencrypted authentication, FTP clients do not properily confirm that they are connecting to the correct server that the user thinks they are before sending the password - Passive network sniffing - sessions can be monitored by a third party. SFTP protects limits the usefulness of passive sniffing. - Man-in-the-middle attack - even if OTP is used for authentication, it is easy to take over/continue an established authenitcated session with FTP. SFTP will protect against man-in-the-middle and session stealing. - On-the-fly compression security holes - SFTP does support on-the-fly compression (compressing files during transfer which aren't normally stored in a compressed format) but doesn't have the security holes that have appeared in FTP servers which have this capablity hacked in (such as wu-ftpd). - Wide open network ACLs (Access Control Lists) to allow active FTP to work. The FTP "data channel" may make a return connection to any port above 1024. If you deny all in-bound TCP SYN packets then SFTP will continue to work but some FTP clients and/or servers will fail to fall back to passive FTP. - Connecting to non-standard ports through NAT - most NAT devices will only allow active FTP sessions to work if the command channel is to the default TCP port 21 (or the NAT device is explicited configured to recognize the non-standard port for FTP). SFTP sessions can be established through a NAT device even if connecting to a non-standard (even non-privilaged) port without any additional modification to the NAT device or even if the NAT device does not support FTP at all. ... the list goes on. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
