Understanding the risk of non SSL login forms

Question

As a user of web applications, I tend to only sign up for services that use SSL secured login forms. As a developer, I know the risk is that non SSL forms are transmitted in plain-text and an unscrupulous individual could "sniff" the HTTP traffic and ascertain my login and password.

However, what is the true risk or possibility of this happening if I'm say, at home, on my DSL or Cable internet connection? Where would the packet sniffer need to be running? Could packets be sniffed at any point back to the server? Is it easier to "sniff packets" in a corporate network with a larger LAN, as opposed to being at home?

I've developed web applications for quite a while, but I've never truly understood this. I would love to get some clarification on this.

Thanks.

Answer 1

Cable is fairly easy to sniff packets as it's a shared broadcast medium. Work networks, not so much. Typically switched, someone would have to target you specifically (or do a general port monitoring setup) to sniff your traffic. DSL is direct to the ISP, so not so much there. Once it's on the net, the realistic chances of someone stealing it are very low. Accounts are almost always stolen by either hacking a database, or stealing info off of unsecured wireless. And of those 2, hacking the database directly has the best risk/reward ratio so it's the most popular.

Answer 2

• "However, what is the true risk or possibility of this happening": Depends on a lot of factors. The largest would be the site you are using, banking would be higher than say StackOverflow.
• "Where would the packet sniffer need to be running": It could be on any node the data runs through (including malware on your machine). To see the amount of nodes a simple traceroute will show you.
• "Could packets be sniffed at any point back to the server": Yes
• "Is it easier to "sniff packets" in a corporate network with a larger LAN, as opposed to being at home": Nope, the requirements are the same. Get control of a node the packets move through and add a sniffer.

Answer 3

packets don't magically travel straight from your network to the server. packets will typically traverse a number of different networks before reaching their final destination. at any point in the chain someone could be capturing traffic.

Answer 4

Actually, depending on your network setup, you may be at higher risk at home, as people wardrive. If your network has security, and the neighbor's does not, the risk is much, much lower, of course.

Anytime someone can get a listener between you and the destination, whether it is on your home network, or some large network, they can sniff.

The risk, overall, is fairly low, as not just anyone can sniff at any router. But, not using SSL means you are placing a lot of trust in people you do not know.

I treat it this way. If a site has something I want, but no SSL, I will do it if there is no financial information passed. On these sites, I use a "spamcatcher" email. If the account is sniffed, there is no major damage, as it goes to an email I rarely check. :-)

Answer 5

It's ever easier to sniff packets in your network. So WLAN offers a lot of danger. If another computer is connected to your switch/router, it can sniff packets by manipulationg the router/switch functionality (ARP Spoofing/Poisioning), see: link text.

A sniffing person in the WAN have to do a lot more work! So your IP must be known and the attacker must manipulate one node on the way of your packets to sniff packets from there.

Answer 6

I think it's because:

1. You can't control where your user will log into your system
2. You can't be sure your ISP won't sniff your packet. (What if some evil hacker had managed to do that)

It's just the Internet. There is not much you can do with the others. The best way is to secure yourself.

Answer 7

The packet can be sniffed absolutely anywhere on the route between client and server. The attacker just needs to get physical access to one of those networks.

Obviously the closer you are to a 'trunk' (ISP) rather than a 'leaf' (Home router, home computer), the more stuff you can sniff.

With DNS spoofing, an attacker can modify that route so that it passes through a system they control.

Possibly the easiest way to get a feel for this is to try it for yourself. Install Wireshark, and see how easy it is to watch stuff that passes by.

Answer 8

Run traceroute. Literally every interface or router between you and the destination can capture your packets.

Starting with your own computer running a packet sniffer without your knowledge, perhaps as a result of infection.

Answer 9

The risk of your traffic being sniffed on a node between your ISP and the destination is remote. You would be one amongst millions and it takes a non-trivial amount of processing power at that level to perform packet inspection to identify packets carrying login information.

The real risk is at local network, as it has been pointed out. The 2 most common scenarios are:

1. An infected computer or malicious user employs tricks like ARP poisoning to sniff all unencrypted traffic. ARP poisoning is fairly unnoticeable on low traffic networks. On high traffic networks it will cause noticeable performance degradation and probability of detection increases. The effectiveness of ARP poisoning maybe reduced by diligent network partitioning.

2. Someone has control of the gateway. This is probably the worst scenario, as all internet traffic passes through the gateway. Depending on how clever the attacker is, this can be very difficult to detect.

SSL guards against sniffing, and it has another advantage you might not be aware of: SSL allows you be sure the entity receiving your passwords and other details is who you think it is.

If say you were victim of DNS poisoning where someone redirects you to a malicious site which looks exactly like the legitimate website, you would have no way of knowing. With SSL you would get a warning/error that the site does not have a valid certificate which would alert you that all is not as it should be.

Personally I tailor my passwords to whether or not information travels over HTTPS. I do this because it is inevitable that eventually I will need login over HTTP on a untrusted network.

Cheers, Steve