FTP transmits user id and password in plain text? Best case/ worsecase analysis requested

[RayLopez99]

From the below it seems FTP transmits id/password in plaintext. I use
FTP when "publishing" my Visual Studio apps to my website. The
initial handshake of the FTP program has my ID and password in it.

What I'd like to discuss are two topics: worse case and best case for
somebody intercepting my user id and password when I FTP from inside
of Visual Studio (which has an FTP client built into it).

I don't know anything about this subject, but here is a guess, along
the lines of what I'd like to hear from you experts. My guess is not
based on knowledge of how 'packet sniffing' is done, just a
conjecture.

Worse case: "Your FTP password and ID can easily be intercepted, not
just in real time by a packet sniffer such as {INSERT NAME HERE} but
also because messages are stored on most servers from about 30 minutes
to up to 24 hours. A sysop can easily read any plain text stored on
these servers. Further, it's well known that many FTP servers are
buggy and have viruses on them that redirect any text message packets
received."

Best case: "While it's true that your FTP password and ID can be
intercepted in theory, in most cases, between 95% to 99% of the time,
this is not easy to do, because most FTP servers have firewalls on
them that will hide all open ports, making it difficult for a packet
sniffer to attach to a port and intercept any incoming data. Further,
since FTP is typically a 'point-to-point' connection, between your
machine and the server, there are no 'hops' between the two machines,
which means that there's little opportunity for a 'man-in-the-middle'
proxy attack. Hence, unless there's a packet sniffer attached to one
of the open ports, which again is unlikely due to the FTP server
firewall, in most cases, 95-99% of the time, your ID and password will
not be read".

Again, I'm making up this best case/ worse case stuff just to get the
ball rolling. I have no idea of what I'm talking about, that's why
I'm asking you.

Any comments?

RL


http://www.raditha.com/php/ftp/security.php

Security issues in FTP

Send your password in clear text

The biggest problem with FTP is that the server can only handle
usernames and passwords in plain text. This is one of the reasons why
the root account cannot be used for FTP access on most servers. The
same applies for telnet.

FTP is not the only protocol that sends everything in the clear, POP,
IMAP, Jabber are some other equally guilty protocols. The difference
however is that FTP is very commonly used to upload contents to
various kinds of servers including webservers. Someone who sniffs your
mail server might read your private mail, but someone who sniffs your
FTP password can deface your website. Matters have not been helped by
the fact that some FTP servers are notoriusly buggy.

For these reasons there are various alternatives including Secure FTP
(SFTP), which despite the name is quite different from FTP. SFTP
applies encryption on all messages between the client and the server.
There is also another alternative FTPS. Losely speaking we can think
of FTPS being to FTP what HTTPS is to HTTP.

Usernames and passwords are not the only things that are sent over
clear text. The files themselves are uploaded or downloaded without
any encryption at all. That online store you buy your T-shirts from
might give you an HTTPS page to enter your credit card, and their
accountants maybe downloading the card details over FTP!

Having said all that this article is not intended to be an indepth
study of cryptography, rather it's intended to give you a small amount
of background information as we work towards building a FTP client
using PHP.

 

[David H. Lipman]

From: "RayLopez99" <[email protected]>

| From the below it seems FTP transmits id/password in plaintext. I use
| FTP when "publishing" my Visual Studio apps to my website. The
| initial handshake of the FTP program has my ID and password in it.

| What I'd like to discuss are two topics: worse case and best case for
| somebody intercepting my user id and password when I FTP from inside
| of Visual Studio (which has an FTP client built into it).

| I don't know anything about this subject, but here is a guess, along
| the lines of what I'd like to hear from you experts. My guess is not
| based on knowledge of how 'packet sniffing' is done, just a
| conjecture.

| Worse case: "Your FTP password and ID can easily be intercepted, not
| just in real time by a packet sniffer such as {INSERT NAME HERE} but
| also because messages are stored on most servers from about 30 minutes
| to up to 24 hours. A sysop can easily read any plain text stored on
| these servers. Further, it's well known that many FTP servers are
| buggy and have viruses on them that redirect any text message packets
| received."

| Best case: "While it's true that your FTP password and ID can be
| intercepted in theory, in most cases, between 95% to 99% of the time,
| this is not easy to do, because most FTP servers have firewalls on
| them that will hide all open ports, making it difficult for a packet
| sniffer to attach to a port and intercept any incoming data. Further,
| since FTP is typically a 'point-to-point' connection, between your
| machine and the server, there are no 'hops' between the two machines,
| which means that there's little opportunity for a 'man-in-the-middle'
| proxy attack. Hence, unless there's a packet sniffer attached to one
| of the open ports, which again is unlikely due to the FTP server
| firewall, in most cases, 95-99% of the time, your ID and password will
| not be read".

| Again, I'm making up this best case/ worse case stuff just to get the
| ball rolling. I have no idea of what I'm talking about, that's why
| I'm asking you.

| Any comments?

| RL


| http://www.raditha.com/php/ftp/security.php

| Security issues in FTP

| Send your password in clear text

| The biggest problem with FTP is that the server can only handle
| usernames and passwords in plain text. This is one of the reasons why
| the root account cannot be used for FTP access on most servers. The
| same applies for telnet.

| FTP is not the only protocol that sends everything in the clear, POP,
| IMAP, Jabber are some other equally guilty protocols. The difference
| however is that FTP is very commonly used to upload contents to
| various kinds of servers including webservers. Someone who sniffs your
| mail server might read your private mail, but someone who sniffs your
| FTP password can deface your website. Matters have not been helped by
| the fact that some FTP servers are notoriusly buggy.

| For these reasons there are various alternatives including Secure FTP
| (SFTP), which despite the name is quite different from FTP. SFTP
| applies encryption on all messages between the client and the server.
| There is also another alternative FTPS. Losely speaking we can think
| of FTPS being to FTP what HTTPS is to HTTP.

| Usernames and passwords are not the only things that are sent over
| clear text. The files themselves are uploaded or downloaded without
| any encryption at all. That online store you buy your T-shirts from
| might give you an HTTPS page to enter your credit card, and their
| accountants maybe downloading the card details over FTP!

| Having said all that this article is not intended to be an indepth
| study of cryptography, rather it's intended to give you a small amount
| of background information as we work towards building a FTP client
| using PHP.

This is NOT a virus/malware issue.

This is a TCP network protocol issue and is not On Topic here.

 

[Slarty]

From: "RayLopez99" <[email protected]>

| From the below it seems FTP transmits id/password in plaintext. I use
| FTP when "publishing" my Visual Studio apps to my website. The
| initial handshake of the FTP program has my ID and password in it.

This is NOT a virus/malware issue.

This is a TCP network protocol issue and is not On Topic here.

And that's why you had to quote the whole lot again?

I never saw the original (what a loss), I use my gmail filter.

 

[David H. Lipman]

From: "Slarty" <[email protected]>


| And that's why you had to quote the whole lot again?

| I never saw the original (what a loss), I use my gmail filter.

It of Off Topic, it wasn't spam.

 

[RayLopez99]

From: "RayLopez99" <[email protected]>

| From the below it seems FTP transmits id/password in plaintext.  I use
| FTP when "publishing" my Visual Studio apps to my website.  The
| initial handshake of the FTP program has my ID and password in it.

| What I'd like to discuss are two topics:  worse case and best case for
| somebody intercepting my user id and password when I FTP from inside
| of Visual Studio (which has an FTP client built into it).

| I don't know anything about this subject, but here is a guess, along
| the lines of what I'd like to hear from you experts.  My guess is not
| based on knowledge of how 'packet sniffing' is done, just a
| conjecture.

| Worse case:  "Your FTP password and ID can easily be intercepted, not
| just in real time by a packet sniffer such as {INSERT NAME HERE} but
| also because messages are stored on most servers from about 30 minutes
| to up to 24 hours.  A sysop can easily read any plain text stored on
| these servers.  Further, it's well known that many FTP servers are
| buggy and have viruses on them that redirect any text message packets
| received."

| Best case: "While it's true that your FTP password and ID can be
| intercepted in theory, in most cases, between 95% to 99% of the time,
| this is not easy to do, because most FTP servers have firewalls on
| them that will hide all open ports, making it difficult for a packet
| sniffer to attach to a port and intercept any incoming data.  Further,
| since FTP is typically a 'point-to-point' connection, between your
| machine and the server, there are no 'hops' between the two machines,
| which means that there's little opportunity for a 'man-in-the-middle'
| proxy attack. Hence, unless there's a packet sniffer attached to one
| of the open ports, which again is unlikely due to the FTP server
| firewall, in most cases, 95-99% of the time, your ID and password will
| not be read".

| Again, I'm making up this best case/ worse case stuff just to get the
| ball rolling.  I have no idea of what I'm talking about, that's why
| I'm asking you.

| Any comments?

| RL

|http://www.raditha.com/php/ftp/security.php

| Security issues in FTP

| Send your password in clear text

| The biggest problem with FTP is that the server can only handle
| usernames and passwords in plain text. This is one of the reasons why
| the root account cannot be used for FTP access on most servers. The
| same applies for telnet.

| FTP is not the only protocol that sends everything in the clear, POP,
| IMAP, Jabber are some other equally guilty protocols. The difference
| however is that FTP is very commonly used to upload contents to
| various kinds of servers including webservers. Someone who sniffs your
| mail server might read your private mail, but someone who sniffs your
| FTP password can deface your website. Matters have not been helped by
| the fact that some FTP servers are notoriusly buggy.

| For these reasons there are various alternatives including Secure FTP
| (SFTP), which despite the name is quite different from FTP. SFTP
| applies encryption on all messages between the client and the server.
| There is also another alternative FTPS. Losely speaking we can think
| of FTPS being to FTP what HTTPS is to HTTP.

| Usernames and passwords are not the only things that are sent over
| clear text. The files themselves are uploaded or downloaded without
| any encryption at all. That online store you buy your T-shirts from
| might give you an HTTPS page to enter your credit card, and their
| accountants maybe downloading the card details over FTP!

| Having said all that this article is not intended to be an indepth
| study of cryptography, rather it's intended to give you a small amount
| of background information as we work towards building a FTP client
| using PHP.

This is NOT a virus/malware issue.

This is a TCP network protocol issue and is not On Topic here.

Where would it be on topic?

RL

 

[David H. Lipman]

From: "RayLopez99" <[email protected]>


| Where would it be on topic?

What does "microsoft.public.dotnet.languages.csharp" have to do with this ?
Please don't add more groups where the subject matter is Off Topic. It wasn't even part
of the original post.

Since you are talking about SFTP, alt.computer.security may be appropriate.

Additionally, alt.comp.networking.connectivity may be appropriate.

 

[Arne Vajhøj]

Where would it be on topic?

Most likely not here either.

But FTP should not be used on an untrusted network.

Switch to SFTP or FTPS.

Arne

 

[idbeholda]

Using FTP is only as insecure as the system that is making use of the
credentials. If the "security issue" of FTP is really that big of a
problem, I don't think we would have vendors offering applications
that make use of said protocol. Good luck with making a "secure" ftp
client with php. The security will only be as good as the user and
the browser.

 

[RayLopez99]

From the below it seems FTP transmits id/password in plaintext.  I use
FTP when "publishing" my Visual Studio apps to my website.  The
initial handshake of the FTP program has my ID and password in it.

What I'd like to discuss are two topics:  worse case and best case for
somebody intercepting my user id and password when I FTP from inside
of Visual Studio (which has an FTP client built into it).

I don't know anything about this subject, but here is a guess, along
the lines of what I'd like to hear from you experts.  My guess is not
based on knowledge of how 'packet sniffing' is done, just a
conjecture.

Worse case:  "Your FTP password and ID can easily be intercepted, not
just in real time by a packet sniffer such as {INSERT NAME HERE} but
also because messages are stored on most servers from about 30 minutes
to up to 24 hours.  A sysop can easily read any plain text stored on
these servers.  Further, it's well known that many FTP servers are
buggy and have viruses on them that redirect any text message packets
received."

Best case: "While it's true that your FTP password and ID can be
intercepted in theory, in most cases, between 95% to 99% of the time,
this is not easy to do, because most FTP servers have firewalls on
them that will hide all open ports, making it difficult for a packet
sniffer to attach to a port and intercept any incoming data.  Further,
since FTP is typically a 'point-to-point' connection, between your
machine and the server, there are no 'hops' between the two machines,
which means that there's little opportunity for a 'man-in-the-middle'
proxy attack. Hence, unless there's a packet sniffer attached to one
of the open ports, which again is unlikely due to the FTP server
firewall, in most cases, 95-99% of the time, your ID and password will
not be read".

Again, I'm making up this best case/ worse case stuff just to get the
ball rolling.  I have no idea of what I'm talking about, that's why
I'm asking you.

Any comments?

RL

http://www.raditha.com/php/ftp/security.php

Security issues in FTP

Send your password in clear text

The biggest problem with FTP is that the server can only handle
usernames and passwords in plain text. This is one of the reasons why
the root account cannot be used for FTP access on most servers. The
same applies for telnet.

FTP is not the only protocol that sends everything in the clear, POP,
IMAP, Jabber are some other equally guilty protocols. The difference
however is that FTP is very commonly used to upload contents to
various kinds of servers including webservers. Someone who sniffs your
mail server might read your private mail, but someone who sniffs your
FTP password can deface your website. Matters have not been helped by
the fact that some FTP servers are notoriusly buggy.

For these reasons there are various alternatives including Secure FTP
(SFTP), which despite the name is quite different from FTP. SFTP
applies encryption on all messages between the client and the server.
There is also another alternative FTPS. Losely speaking we can think
of FTPS being to FTP what HTTPS is to HTTP.

Usernames and passwords are not the only things that are sent over
clear text. The files themselves are uploaded or downloaded without
any encryption at all. That online store you buy your T-shirts from
might give you an HTTPS page to enter your credit card, and their
accountants maybe downloading the card details over FTP!

Having said all that this article is not intended to be an indepth
study of cryptography, rather it's intended to give you a small amount
of background information as we work towards building a FTP client
using PHP.

 

[unruh]

Yes, it does. Well known. That is why people suggest not using ftp but
something like sftp, or scp, or rsync with ssh, or...

Your worst case is closer to the reality. The sysop on the remote
machine or your machine can always get your password, so if you do not
trust them do not use their machines. A packetsniffer does not need to
"attach to a port" it just reads the messages going by ( try tcpdump
sometime and look at its options).


This ball is so old all the seams have burst from overuse. If you are
concerned, do not use ftp. If you use ftp make sure you do not use a
password you use elsewhere and assume it is comprimized.

 

[Bob K]

Your worst case is closer to the reality. The sysop on the remote
machine or your machine can always get your password, so if you do not
trust them do not use their machines. A packetsniffer does not need to
"attach to a port" it just reads the messages going by ( try tcpdump
sometime and look at its options).

I'm not sure that is true, at least in many cases. I have several Linux
computers, a couple with multiple user accounts on them. The passwords
are stored encrypted, and I honestly don't know of any good packages to
retrieve them. The software to do that may be out there, but I am not
aware of it.

When I set an account up for a user, I use a temporary password, and the
user is told to change it. If they forget what they changed it to, all
I can do is reset it to something new for them.

I know on Windows machines that passwords can be recovered in many
cases. But then, on many of the client side computers, the password
managers and the like may make your stored passwords available to you in
plain text. Not necessarily great when several people have access to
the machine!

And, in the dim past, in another life, I administered some computers
where passwords were stored in plain text. But, hopefully, all those
computers have been recycled!

....Bob

 

[RayLopez99]

Your worst case is closer to the reality. The sysop on the remote
machine or your machine can always get your password, so if you do not
trust them do not use their machines. A packetsniffer does not need to
"attach to a port" it just reads the messages going by ( try tcpdump
sometime and look at its options).

If that's the worse case, I will sleep soundly. My sysop is not a
problem--social engineering aside--I'm afraid of evil hackers, not
some underpaid sysop.

As for your packetsniffer, I'm not sure you're correct, and in any
case I think for it to "read messages going by" it has to live in
memory--so it would technically qualify as a virus, and thus it can be
detected. http://en.wikipedia.org/wiki/Tcpdump - "Tcpdump works on
most Unix-like operating systems: Linux, Solaris, BSD, Mac OS X, HP-UX
and AIX among others. In those systems, tcpdump uses the libpcap
library to capture packets" - well my sysop, and the web server I use,
use Microsoft Windows products only, so Tcpdump is out. If there's an
equivalent utility for Windows, and I'm sure there is, again, it would
only be accessible to the sysop, which is not a concern of mine. I'm
afraid of strangers in the middle between my computer and the web
server, not the guy at the web server.

RL

 

[Bob K]

If that's the worse case, I will sleep soundly. My sysop is not a
problem--social engineering aside--I'm afraid of evil hackers, not
some underpaid sysop.

As for your packetsniffer, I'm not sure you're correct, and in any
case I think for it to "read messages going by" it has to live in
memory--so it would technically qualify as a virus, and thus it can be
detected. http://en.wikipedia.org/wiki/Tcpdump - "Tcpdump works on
most Unix-like operating systems: Linux, Solaris, BSD, Mac OS X, HP-UX
and AIX among others. In those systems, tcpdump uses the libpcap
library to capture packets" - well my sysop, and the web server I use,
use Microsoft Windows products only, so Tcpdump is out. If there's an
equivalent utility for Windows, and I'm sure there is, again, it would
only be accessible to the sysop, which is not a concern of mine. I'm
afraid of strangers in the middle between my computer and the web
server, not the guy at the web server.

RL

Well, I use tcpdump to sniff traffic going out on the internet. While I
don't make an attempt to capture plain text passwords or such, I suppose
I could.

I have a computer that looks at the traffic between a DSL modem and the
router. It is looking for unwanted traffic. Attempts to access ports
that are not available, and traffic that should not be going out onto
the internet.

Example, all email traffic going out is using secure servers -- so there
should be no outbound port 25 traffic. There are one or two processes
that at times will make an attempt to contact a mail server on port 25.
(My ISP blocks those for me.) I haven't pinned down what they are,
but am aware of it.

There should be no inbound requests to port 25. Likewise, I don't run a
web server on port 80, so there should be no incoming traffic there,
either. But, there is (on both)! These are hackers scanning for
available vulnerable computers. While I have the router blocking them,
it's still nice to be aware of.

In one case I found outbound traffic attempted to a private
(non-routable) address. That was due to a misconfiguration, and was
corrected.

So, while I might be considered the 'stranger in the middle', in my case
I'm only sniffing my own internet traffic, and I think for legitimate
purposes.

I sincerely don't think the sniffing I am doing is able to be detected,
at least not easily!

And, the Wiki page referenced does mention WinDump as a Tcpdump program
for Windows.

....Bob

 

[Dustin]

If that's the worse case, I will sleep soundly. My sysop is not a
problem--social engineering aside--I'm afraid of evil hackers, not
some underpaid sysop.

As for your packetsniffer, I'm not sure you're correct, and in any
case I think for it to "read messages going by" it has to live in
memory--so it would technically qualify as a virus, and thus it can
be detected. http://en.wikipedia.org/wiki/Tcpdump - "Tcpdump works
on

A virus? No, it wouldn't. A virus intentionally replicates and true
definition even states a host is REQUIRED; to seperate a virus from a
worm, and to make the distinction when a virus has worm capabalities
as well. In either case, replication is intentionally taking place;
tcpdump doesn't replicate it's code into other files, the mbr or
anywhere else on your system.

 

[FromTheRafters]

[...]

As for your packetsniffer, I'm not sure you're correct, and in any
case I think for it to "read messages going by" it has to live in
memory--so it would technically qualify as a virus, and thus it can be
detected.

***
Actually, while true worms must 'live in memory' the humble virus can
wait silently in slow storage.
***