Now I don’t consider myself to be some uber-programmer, more like your garden variety enthusiast who knows how to work his way through a Google search to find what he’s after. Still I’m often amazed to find those who call themselves programmers (and even more worrying, convince others to pay them) falling for things that really should be obvious to anyone with half a brain about them. Sure I’m not immune to making some serious logic errors or just plain WTFery but something as fundamental as not sending your users’ passwords across the Internet in such a way that anyone with freely available packet capture software or even a Firefox plugin can read them is one of those things that really should go without saying. Traditionally this is done by encrypting the connection between you and the user using SSL so that anyone listening in just sees garbage and not your user’s password.
Securing a web connection between a user and your server, in the Microsoft world at least, doesn’t take too much configuration to get it working. For my pet project it was little more than adding a line of code at the top of the API implementation, installing a SSL certificate on my server and creating a client access policy file to enable cross domain communication. All in all I went from an API that sent everything in clear text to a fully secured API in a little under 2 hours with a good half of that being spent googling and sussing out which SSL provider I was going to go with. Still it seems that nearly every month I hear of at least one big start-up or long running service that fails to implement encryption for their login details, potentially endangering their users.
The first such company that I heard about was Foursquare, a popular geo-social networking application. Now I had been using that application for quite some time before I heard about them not encrypting anything so you can imagine how I felt when I found out they had let that little detail slip their minds for well over a year. Sure they were quick to fix it but who knows it would have gone unfixed had no one said anything about it. Their close rival Gowalla also neglected to implement any sort of secure communications for almost 3 years, making me wonder how something like that could go unnoticed for so long.
It doesn’t just stop there either. Last month saw not one but two companies being outed as passing login information around in clear text. The first was Napster (yeah even I’m surprised they’re still around) who not only has no encryption on their login forms but also sends users their login credentials when trying to get them to renew. Then just 2 weeks later it was revealed that the recent hit photo sharing app Instagram was also spreading information over the web that it shouldn’t be. To Instagram’s credit they were quick on getting a fix out, but it still seems like a fundamental error to make when you’re sending sensitive data over the Internet.
For all the vitriol that I’m launching at these companies I can understand the mindset that leads up to this kind of mistake happening. For the longest time I developed everything without SSL as it made debugging the whole application that much easier. Even with Fiddler’s SSL decrypting feature it still doesn’t seem to work quite right when cracking open encrypted communications so the solution of just turning SSL off works much better. Then when it comes time to deploy not only is your app not configured to use SSL all your API calls are made to the unsecured endpoint. If you follow good coding practices the latter shouldn’t be too hard to fix (your API URL should be a global variable) but getting the web server to serve out a SSL connection can take a bit of wrangling to get done, especially if you don’t control the web server yourself. So you deploy the code and hope that no one notices as at least 5 companies have gotten away with such things for years at a time.
Security is one of those things that’s always the lowest priority until something happens that forces your hand. It’s one of the most laborious aspects of developing a system as it’s usually not very interesting and only serves to increase the amount of work you have to do. Still it is so fundamental to get these things right from the get go that it still shocks me how many multi-developer companies manage to let things like that slip through the cracks. Perhaps it’s just my system administrator background that’s made security such a primary focus for me but really it should be one of the prime considerations for anyone looking to build a system with users on the Internet.
