How is password stolen over non-SSL connection?

Question

I am semi-embarrassed to ask this question having worked in the field for 20 years, but can someone describe to me why I should run SSL on any web site that uses authentication? I understand the bigger "why" issues (people use same password on blog and bank) and I am assuming that the passwords are stored encrypted on the site database, but I want to really, simply, explain the technical risk of transmitting non-SSL passwords in a way that is grounded in practical application.

Example: I have a wordpress blog I am hosting on bluehost. I go to the login page and enter my username and password and press submit. That information is sent to the web server in an unencrypted HTTP POST.

Now if someone is on my network or any network where the packets are broadcast, running a sniffer, they can get read the packets and write code to parse for interesting words like "login" or "password." Is that how it works?

How would this work in my example? Assume there is nobody on my home network--that otherwise, I have taken appropriate security measures for devices that are within my control. How does the hacker get in between me and my website? Would he or she just log on to their own bluehost account and be able to monitor all traffic on the subnet? Or could they be ANYWHERE in between; e.g. I'm on Verizon FIOS, so maybe they get onto (install an automated process) a server somewhere within the Verizon network. Or could they literally be anywhere?

My understanding of networking is that my device broadcasts packets with a destination IP that is the bluehost server. Those packets get "noticed" and resent by my router to upstream routers and switches that are part of the Verizon network. As they cross each subnet, the potential exists for any device sitting on that network to observe the packet as it is broadcast locally. Good practices would have those networks set up with security that did not result in people being able to get in the middle...but once the information gets to bluehost, then we are at their mercy in terms of broadcast packets. Once the http server "hears" the POSTed information, it encrypts and compares against the locally-encrypted password.

Is this an accurate way to think about it and explain to others?

Answer 1

When data is exchanged over the Internet, it hops from router to router, starting with the source (your desktop computer) and ending with the destination (the authentication server to which you are sending the password). All the routers, by definition, "see" the data. Moreover, all machines which are directly plugged with the link between any two routers can also see the data.

In practice, for low-level attackers, password sniffing mostly occurs through three mechanisms:

1. Close to the user (you). E.g. you are using your laptop and connecting through a WiFi access point; other machines connected to the same access point see all your traffic. Note that "taking steps" to prevent such local attackers can be quite difficult (for instance, forget it is WiFi is involved).

2. Close to the server. Typically, servers are mass-hosted in some shared facilities, and indelicate server owners may spy on their neighbours. Whether this is possible or even easy depends a lot on the competence of the network administrators at the hosting site.

3. Through active redirection. When you want to connect to a server, you actually type a name, and then the DNS finds the IP address which corresponds to that name. Your machine will send the packets to that IP address. However, the DNS, as a whole, is poorly protected, and can be altered by malicious individual. A bad guy may then transparently redirect your packets to his own machines; he may even inspect the data but still forward it to their true destination, which makes him a Man-in-the-Middle. At that point, the attacker sees all the data, including the password and whatever the password protects, and can hijack the connection at any time.

All three kinds of sniffing can be put into practice, and are actually applied, by students with a few hundreds of dollars of budget and a lack of morality. More advanced criminals can employ other active methods, e.g. trying to disturb dynamic routing mechanisms. Or simply bribe employees at network facilities (in particular Internet Service Providers).

SSL (now known as "TLS") fixes things in several ways:

• It encrypts all the data with a key that only the two end points (your machine and the server) know, effectively keeping out passive eavesdroppers.
• It uses the server's certificate, so that the client can gain some confidence that it is indeed talking to the intended genuine server, not an attacker-controlled fake. This is the point of the padlock picture and the scary warnings in Web browsers.
• SSL ensures continuous integrity, meaning that an active attacker cannot simply put himself in MitM position, forward data bytes back and forth, and then hijack the connection after the authentication has taken place. The protection granted by SSL is both for confidentiality (data is unreadable by outsiders) and integrity (data cannot be altered by outsiders), and this encompasses the complete connection, not just the initial steps.

With SSL active and no certificate validation issue, you can send your password with reasonable guarantee that only the intended server will see it. How the server verifies the password is irrelevant here. Moreover, and again thanks to SSL, the server can assume that the initial authentication is valid for all subsequent traffic over the same connection, because SSL guarantees that it will be talking to the same client all along.