What are the attack vectors for passwords sent over http?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

I can agree with KevinM's musings toward answering his own questions, and John Gardeniers is pointing in the correct direction. I must also agree with what silky said, in, "ideally - the general public would never log in to a site that doesn't have an SSL based login screen.", and point out that this is, however, not the contemporary case at all.

I disagree with silky's tone (probably unintentional), which leads toward the ubiquitous perception that, "the general public", is stupid. KevinM's client clearly has no concept of a need for SSL, and that is your average person in a nutshell. They aren't stupid, they simply do not know. To say, "you need this", will illicit the response, "I've lived x years without it, and I'll live x more just fine", or perhaps even a worse response, "I hate being told what I need." So, be careful!

Your concern is legitimate, Kevin. Your customer does need an SSL certificate. I think your real concern should be how to sell them one. It isn't only the user logins to be concerned about, but the administrator and operator logins which would also benefit from being protected by SSL.

Yes, there are other things to be concerned about in this regard, even more so than packet sniffing, such as XSS. They're numerous, and well documented.

Answer 6

in the entire route followed by packet, if its over HTTP can be sniffed and data can be seen... even if you use HTTP in Proxy like TOR... using harvesting-attack,etc. one can trick the Proxy to leak the data-packets... so if there is anything near to sensitive (passwords, personal details, private images, etc.)... it's only suitable to transfer them over HTTPS.

That too, even HTTPS is vulnerable with wrong implementation and their are several SSL Attacks applicable over it... still those can be avoided with careful implementation.

But, using HTTP for plain-text is like inviting even the newbie n/w kids to sniff away the passwords.