Hello, my name is Taylor Hughes.

While checking out some other to-do list options about four months ago, I noticed something disturbing: Ta-da List, a popular to-do list app and top Google result for “to-do list”, doesn’t use SSL for its login or sign-up forms.

This was shocking to me, since using HTTPS for authentication has always been a no-brainer. Since then, however, I’ve been flabbergasted to find two new services that also launched without HTTPS support for sign-up and authentication: Brizzly, a twitter client, and TeuxDeux, another to-do list app. Brizzly is awesome — really, I love it — but I haven’t used it since I discovered this issue a month or so ago. (Update: Brizzly has added HTTPS for authentication; I am free to use it again.)

I contacted support on all three sites — which I consider to be high-profile, professional efforts — and all three essentially said they’d get around to adding SSL for authentication at some point in the future.

Frankly, I don’t understand how they can consider plaintext password transmission acceptable for their users, now or ever.

Perhaps the problem is misunderstood. Maybe web developers aren’t concerned with unsecured wireless networks or the off chance that somebody is doing deep packet inspection in between their users’ web browsers and their datacenters.

But I think they should be concerned — especially about unsecured wireless networks — and not risk exposure of their users’ sensitive data.

Vulnerable information: Users’ passwords are valuable

My first assumption going into this is that passwords are valuable information and users trust us as web developers to keep them safe.

Passwords are valuable because people reuse passwords all the time. I work at a network security company, and even I reuse the same set of passwords over and over again for a variety of services I use — it’s just unavoidable when you have to sign up for a new web site virtually every day.

Thus, the password I use at some random site is probably the same password I use for any number of other sites — and most people probably use the same password for their bank accounts, too. Maybe even the same username.

This isn’t how things have to be — you can store your passwords in the Apple Keychain or use a program like 1Password to remember unique, complicated passwords for you for each site you use. But, for the typical user, this is not the case.

Note: I am not as worried about sessions being hijacked because session hijacking has a limited scope. For example, with a hijacked twitter session, someone could post malicious tweets, but he can’t log into my bank’s web site. Passwords are private data that people trust is kept secret.

Anatomy of an insecure login

Here’s how a typical insecure login happens over HTTP:

1. You type your username and password in a form and hit “Login”
2. The browser “form-encodes” the data you typed into the form so it looks sort of like this: username=taylor&password=mypassword
3. A web request is created including the form-encoded data
4. The request data leaves your computer and travels over your local wired or wireless network
5. The request data leaves your home or office, traveling through your ISP’s network
6. The data leaves your ISP and travels to its destination through a variety of core routers and switches, which are generally regarded as secure
7. Your data arrives at the datacenter where the servers live and is routed to the proper destination
8. The server gets your request, checks your credentials and issues you a session cookie, which is something you’ll identify yourself with in subsequent requests
9. The response from the server — including your new session cookie — flows back through the same channels and into your browser.

The parts highlighted in red are places where your password, transmitted in plaintext, could be intercepted. Let’s look at those spots a little more in detail.

Wireless networks: Unsecured wireless as a bullhorn

At home, you probably use WPA or (gasp) WEP security to keep your neighbors from accessing your wireless router. But those technologies also encrypt your network’s traffic, so the hacker sitting outside with a laptop and a Pringles can can’t easily get a look at the juicy gossip you’re reading on Perez Hilton.

Most public access points — coffee shops, airports, etc. — use unsecured wireless networks. These unsecured wireless networks rely on HTTPS and other secure transmission media to protect your sensitive data while it flies through the air. Thus, on an unsecured wireless network, your insecure HTTP requests and AIM conversations and torrent downloads are blasting out over the airwaves for anybody to read.

That’s basically like announcing your passwords over a bullhorn for the entire coffee shop to hear.

You can try this experiment on your home computer: Download Wireshark, start collecting packets from your own network interface, and login to Ta-da List. You’ll see an HTTP packet with a form-encoded version of your login information contained in a HTTP POST request. It looks sort of like this, except the password isn’t blurred out.

It’s right there, in plaintext.

This is easily the most dangerous point for unsecured HTTP transmissions, and the point that should most worry both users who are logging in using an insecure form and the web developers who created them. You should assume that every packet you transmit on an unsecured wireless network is being read by someone else.

Your corporate LAN or ISP, and the datacenter your data ends up in

Your network traffic, somewhere down the line, is probably being siphoned off and monitored by some assortment of devices. The core Internet is not so much a worry, but your local ISP, your corporate LAN or your university’s vast network are probably being tapped at various points and inspected.

Heavy-duty switches nowadays come equipped with ports specifically designed for this: SPAN ports copy the data off for various analyses, or you can buy a network tap to do effectively the same thing. This is how intrusion detection systems work: You plug an IDS into a port that essentially copies off all the traffic on your network, then the IDS performs some packet inspection to figure out if anything bad is going on. You can do this at immense speed, applying “filters” or “signatures” to gigabits of traffic every second without breaking a sweat. IDS technology is extremely popular, making up a huge portion of the cybersecurity performed at nearly every major organization across the globe.

The point is not that security groups are out to get you, it’s that deep packet inspection at line speeds is not difficult.

With the system I work on every day, for example, I could write a filter to extract Brizzly usernames and passwords in just a few minutes. You could even do it with a simple packet capture device filtered by destination IP: You just need access to the network anywhere in between the source and destination.

The sheer volume of the traffic on most big networks is the only thing working to your advantage in this case — it’s nearly impossible to look through everything in detail, so it’s unusual that your password would be stolen over a wired connection. But I would rather not take my chances.

Technology to the rescue: HTTPS

Luckily, it doesn’t matter who is listening if you encrypt HTTP requests containing passwords using HTTPS. SSL uses a public-key handshake to guarantee two things:

1. My password is being transmitted to the correct recipient (Ta-da List, etc.), and
2. My password information is encrypted and unreadable by anyone else who doesn’t own a supercomputer.

Further, it’s easy to configure: You buy an SSL certificate and install it, flip on SSL, write a rewrite directive in your HTTP server, and you’re set — nobody can read your users’ passwords except you. No app code changes necessary.

HTTPS is not going to solve every security problem — how’s your password storage, by the way? — but it’s an easy step in the right direction. Web developers should use HTTPS for sign-up and authentication, no questions asked.

Disclaimer, or qualifier, depending on how you look at it: I work at a network security company that builds a device to analyze networks and figure out who the bad guys are.