What are the attack vectors for passwords sent over http?

I am trying to convince a customer to pay for SSL for a web site that requires login. I want to make sure I correctly understand the major scenarios in which someone can see the passwords that are being sent.

My understanding is that at any of the hops along the way can use a packet analyzer to view what is being sent. This seems to require that any hacker (or their malware/botnet) be on the same subnet as any of the hops the packet takes to arrive at its destination. Is that right?

Assuming some flavor of this subnet requirement holds true, do I need to worry about all the hops or just the first one? The first one I can obviously worry about if they're on a public Wifi network since anyone could be listening in. Should I be worried about what's going on in subnets that packets will travel across outside this? I don't know a ton about network traffic, but I would assume it's flowing through data centers of major carriers and there's not a lot of juicy attack vectors there, but please correct me if I am wrong.

Are there other vectors to be worried about outside of someone listening with a packet analyzer?

I am a networking and security noob, so please feel free to set me straight if I am using the wrong terminology in any of this.

Something to make note of that others haven't mentioned here is that some browsers cache your form data. The default behavior on SSL sites typically is to not cache anything unless you chose "save my password". Typically password fields don't cache anyway, but I've seen some oddities (typically credit-card info, which I know isn't really the topic of the question).

The other thing to note is that SSL Encryption starts at TCP handshake. Once under SSL you cannot distinguish HTTP over SSL from FTP over SSL (aside from assumptions made via port number).

You also cannot distinguish a login request from a "Im just browsing" request, this obfuscates the page-flow from would-be hackers and also makes sure not only your password-data is safe, but your browsing history / cookie data / and any personal information that goes along with your account.

All-in-all if you eliminate man-in-the-middle attacks from the spectrum you cut down on a lot of the potential attacks, that is not to say that your site is 'safe' though. Also zoning policy should help protect you from XSS attacks since you'll be making a zone-change if your user is re-directed out of your site.

The data is vulnerable anywhere along the route, not just the first or last stage. It is quite conceivable that a system involved in the transfer searches out user names, passwords and other sensitive data. It follows therefore that sensitive data should only travel over a link that is secured all the way and of course that is exactly what SSL is for. Depending on what data is involved there may well be local laws that dictate SSL.

There are proxy servers which might store data.

But there is also an obligation to keep users passwords safe. Many users use a limited set of passwords, so an unsafe site might compromise their homebank password for example.

Your analysis is reasonable, IMHO.

The thing to note, I suppose, is that there could be caches in your path. So it may be that the request gets logged somewhere (especially if the login is over GET, which would be terrible).

Probably the thing to consider is that most network access takes place in a area where there are lots of other people on the same network. Work/Uni/School being the main examples. At home you could argue it's less risky, because it's only paths upwards you need to be concerned about.

But really, there is no question here. You use SSL when logging in. Probably the most compelling argument for the guy will be that it makes your website seem more trustworthy, as - ideally - the general public would never log in to a site that doesn't have an SSL based login screen.

But lets be realistic. Almost certainly this attack vector is not the way his system or users will be compromised.

HTH.