No problem at all. Sometimes it is easy for nerds like myself to forget sometimes that other folks don't have to deal with the stuff that I do, which leads me to be lazy sometimes when I talk about something.
My question is: I hear you saying using FTP is bad. Please explain why so I can learn.
The bottom line problem with FTP is really simple. The passwords are sent "in the clear", meaning that anyone who is running software that can "listen" to the chatter on an ethernet link, (I use such software often for troubleshooting network issues), can see both your username, password and the site you are connecting to. This is not a good thing. Way back in the early days of the net, when things were much more civil and trusting, it wasn't such a big issue. These days, there are baddies everywhere so we have to guard against them. Rather than using FTP, there are some alternative programs that you can use that actually encrypt the link between the two computers, even when passing the username/password so someone who might be trying to 'listen in', wouldn't be able to see anything they could use. SCP is the program most often used for this kind of file transfer, though there are others.
Now, I'm not saying that FTP is completely useless, because it isn't. For anonymous file downloads, it rocks because the protocol is fairly efficient, and you can be pretty certain that everyone has some form of FTP on their computer. Many moons ago, you'd use programs like kermit, x-modem, z-modem and others, but they've generally fallen out of favor, though I have seen kermit used even today in very specialized circumstances. Your browser uses anonymous FTP file downloads for some types of file downloads. What happens is that the username used with this type of access will be either "anonymous" or "ftp", with the password as either your email address, or some other random string. The key here is that you're not really authenticating someone with the username/password, which is why it doesn't matter if someone can read it because it wasn't encrypted.
I'm hoping my explanation is clearer this time :-) Anytime you have a question feel free to ask. If I don't know the answer I'll make up something good instead!
Do you have any idea why, so far as I've been able to tell, there's been no effort at creating a standard for halfway-secure web password authentication short of using https://?
To be sure, real https:// is more secure than something like the somewhat ad-hoc proposal here, but what I'm describing here would still be much better than nothing.
To start with, a user who's creating an account on a system must start with some sort of password. This requirement could be handled by having the system randomly generate a default password and email it to the user. The email could be intercepted, but since email gets routed separately from http traffic, there is still some level of security there.
The next step would be to allow the user to log in. For this step, the server would send a small random data payload to the client. The client would encrypt the payload using an MD5 of the operator's password concatenated with some identifier appropriate to the service, and send it back. The server could then verify it for correctness.
The final step would be to allow the user to change his passcode. In this case, the server would perform a password validation as before, but the client's data packet would also include the MD5 of his new passcode (with serivce identifier concatenated), encrypted using the MD5 of the old passcode.
The net effect would be that somebody who intercepted the "welcome" email and every other password-change request would be able to impersonate the user. An attacker who didn't get every password-change request would be unable to decipher any after the one he missed.
The level of security added by doing something like this wouldn't be sufficient for things like banking, but would be good for sites like FR which presently send passwords in the clear.