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.

I’ve spent a lot of time thinking about what I like about programming for a living, what I like about my job in particular and what could make it all even better — and I’ve boiled it down to four dimensions that need to be satisfied by a workplace to make it truly rock. I’ll call them “Taylor’s Dimensions of Developer Happiness.”

If you’re firing on all four cylinders, congratulations — you’ve found a great place to work.

The code: writing good software

As software engineers, the product of our toil is essentially a pile of text files — but the quality and composition of them is vital. Even more important is the collaborative, thoughtful process that goes into creating a lasting set of reusable, maintainable components.

Gauging this category might mean answering questions from the Joel Test, but there’s even more. How about some of these:

• Do you believe in testing? Does someone on your team freak out if a code path is untestable (or untested)?
• Do you do code reviews? Have you been talked into refactoring a nasty bit of code recently?
• Do you have deep discussions about the merit of various source control systems?

All of these things individually are great — but the more that resonates with you, the more likely it is that there’s experience behind the process you’re following to build good code.

The coworkers: working with people you like

I am a strong believer that the people you spend eight hours a day with should be people you’d gladly spend the rest of the evening with at a bar or restaurant. If you can’t get along with them over drinks, you sure as hell won’t be able to build a quality product with them.

That isn’t to say you should be best friends with everyone you work with — just that you enjoy spending the majority of your daily life with them and that you trust in their ability to make decisions that impact you on a daily basis.

This is mostly something that goes without saying, but it’s easy to glaze over or forget the importance of the team’s social makeup when you’re interviewing or distracted by a job offer.

The mission: building a great product

I saw a talk recently by one of the co-founders of Alice.com talking about what has led to the success of his previous start-ups. He said something to this effect: Start-up employees are on a mission to change the world; they need to know the mission and be revved up about the product to make it all come together. In fact, he said the start-up employee is one of the only advantages start-ups have.

Whether or not you work for a start-up, however, the mission is extremely important: You need to be commuting to work every morning for a reason.

You should be able to delve into an exciting summary of the work you’re doing and talk my ear off for about a half hour without stopping. It should keep you up at night. The end result of your work is extremely important: You need to be proud and excited about what you’re doing.

The challenge: learning as you go

The last dimension to developer happiness: The environment you work in should push you with new challenges on a constant basis. This means learning new things and venturing into unknown territory every day.

Lots of different things can be challenging, and in a start-up environment especially, challenges will crop up out of nowhere all the time: technological nightmares, interpersonal conflicts and everythingelseinal challenges abound.

But I think it’s important to put yourself in an environment that breeds those challenges, and to avoid situations you know you can handle.

The… end

And that’s it. This is mostly the product of my working in a small start-up and evaluating the options out there in the rest of the world — so, take it with a grain of salt. I am fairly certain, however, that if you can cover those four bases, the job is a great fit.

I just finished migrating DNZO to run on the webapp framework, after running on Django 1.0 via app-engine-patch for the past several months. I learned a valuable lesson in the process of switching: The webapp framework is really nice and, perhaps more importantly, way faster than using a zipimported version of Django.

It makes sense that using a zipped up copy of Django would be slow: You’re making the webserver inflate a copy of a framework you’re using to serve requests before it can serve them. The most important thing to note here, however, is that App Engine aggressively kills off application instances, especially during the day (when overall system load is presumably higher) — so you don’t get the opportunity to reuse those inflated copies of Django very often.

As a result, I ended up being hit with the initial load penalty frequently: Almost every request during the day took upwards of two full seconds. And that totally sucks.

So, I started out the transition by building a new section of DNZO that uses the webapp framework. Obviously you lose a lot of goodies provided by Django, but the webapp framework provides a basic class structure, some URL mapping and resolution, and it’s generally really nice and easy to extend. It provides nothing I don’t want, and the stuff I do want that it doesn’t have (like straightforward cookie support — really?) is pretty easy to whip up. Before long, I had a basic structure that worked well and I was ready to migrate the rest of DNZO to the same framework.

A few subversion commits later and we have the new version of DNZO: Now with page loads that are about 5 to 10 times faster than when using the zipimport’d version of Django. Fresh page loads usually take between 300 and 500 milliseconds, down from two to three full seconds: the difference between feeling slow and feeling pretty snappy.