On Fri, 18 Apr 2008 15:42:44 EDT, Joey Mengele said:
> I disagree, read the RFC. There are plenty of more secure FTP
> clients such as the OpenSSH.com groups proactive secure Secure FTP
> (sftp) implementation of FTP.
Right, except that SFTP isn't the RFC959 protocol that lives on ports 20/21,
it's an entirely different protocol layered on top of the OpenSSH on port 22.
If you actually *do* "read the RFC", RFC959, section 4.1.1 says:
PASSWORD (PASS)
The argument field is a Telnet string specifying the user's
password. This command must be immediately preceded by the
user name command, and, for some sites, completes the user's
identification for access control. Since password
information is quite sensitive, it is desirable in general
to "mask" it or suppress typeout. It appears that the
server has no foolproof way to achieve this. It is
therefore the responsibility of the user-FTP process to hide
the sensitive password information.
And RFC2228 (FTP Security Extensions) section 1 reminds us:
Although the FTP control connection follows the Telnet protocol, and
Telnet has defined an authentication and encryption option [TELNET-
SEC], [RFC-1123] explicitly forbids the use of Telnet option
negotiation over the control connection (other than Synch and IP).
Also, the Telnet authentication and encryption option does not
provide for integrity protection only (without confidentiality), and
does not address the protection of the data channel.
Of course, the problem is that RFC2228 is *Extensions*. Not part of the
base protocol. And what OpenSSH's SFTP is doing is actually documented
in RFCs 4250 through 4254.
Attachment:
pgpzpGg9Z0Asl.pgp
Description: PGP signature
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/