On Software and Salmonella: Shouldn’t we avoid digital food poisoning?

Meredith Broussard
4 min readSep 24, 2015

--

The most recent revelation from the Ashley Madison hack: aspiring cheaters tend to use pathetic passwords. “123456” was the most popular password in the site’s leaked database, followed closely by “12345,” “password,” and “DEFAULT.”

From a programmer’s perspective, this is not news. People have been using pathetic passwords (and writing their passwords on sticky notes attached to their monitors) since the dawn of the digital age. Cheaters: they’re just like us!

Given the vagaries of human memory, inferior passwords are inevitable. In today’s world, there are simply too many passwords for a single person to remember a different, unique password for each site.

This hack and its pathetic exposed passwords, on top of the revelations about Volkswagen’s car emission subterfuge, has made me think of food poisoning. I wonder if it’s time to start treating software like we treat food. In my kitchen, there are food safety protocols that I follow to make sure I don’t give anyone food poisoning. When I go to a restaurant, I trust that the restaurant is using commercial-grade food safety protocols. Even when I eat from a bodega hot food bar, a location that is ground zero for my paranoid fantasies about listeria/salmonella/e coli/botulism, I know that a restaurant inspector occasionally visits the bodega to make sure that (among other things) the temperature inside the steam table is high enough to inhibit most bacteria that cause food-borne illnesses.

Technology is just as essential as food in today’s society. What if we made some rules to prevent the digital equivalent of food poisoning?

Malicious hacks and data breaches are the norm today, not the exception. Every company with a large trove of user data, especially credit card data, is a prime target for hacking. Home Depot is still dealing with the fallout from its 2014 data breach. The company carries a $100 million insurance policy to deal with cybersecurity claims, and a hefty chunk has been taken out of that policy already. Target’s 2013 data breach resulted in a $67 million settlement with Visa, with more payouts to come from a class action lawsuit made of banks that represent the 40 million consumers whose credit card numbers were stolen in the breach.

Most people are probably trying to decide whether they have sympathy for the Ashley Madison users whose data was breached. Personally, I have sympathy for the programmers who built the Ashley Madison database. They made a cryptographic mistake. The mistake, which was discovered by a password-cracking group called CynoSure Prime, is explained elegantly in an Ars Technica article. The short version: Ashley Madison programmers first encrypted users’ passwords using an encryption protocol called MD5. Later, on 6/14/2012, the programmers switched to encrypting passwords with a different and stronger protocol called bcrypt. But, the programmers neglected to go back and update the old passwords to the newer technology. CynoSure Prime was thus able to quickly decrypt the passwords for 11 million Ashley Madison users.

If you didn’t follow the technological details in the preceding paragraphs, don’t worry — you’re not alone. Few programmers understand the nuances of cryptography, just like few sous-chefs understand exactly why raw eggs on the counter can cause salmonella. None of us can know everything about everything. But in the food world, we can have policies like “wash your hands after handling raw chicken” that effectively minimize the potential spread of harmful germs. The Ashley Madison screw-up is like the digital equivalent of giving patrons salmonella. And it’s not just people who make software for infidelity who are at risk of giving people communicable digital diseases — it’s all of us, because we all build software and we all use software the way that we all make food and we all eat food. We’re all in this together, and we all have a vested interest in staying safe.

So, if software is going to run the world, we probably need to start thinking about it like we think about food. In restaurants, we have rules and inspections. Do we need the same thing for software?

A simple software inspection system could work like any real-world system. Every few months, a person (or an automated program) could examine the software for integrity. The inspector could talk with the developers and IT folks to make sure the correct protocols are being followed, and the software could get a grade. The grades could be published online, so that consumers can see the relative quality of the systems to which we entrust our sensitive data. Software verification systems are commonly available: software validation and verification is a sub-discipline inside software engineering (albeit a not-very-popular one).

It’s time for an inspection system because the Internet era is no longer new. Those of us who went through the first Internet bubble are now (shudder to think) grown-ups. I first learned about the need for password encryption in college in 1991. This means that “don’t store passwords in plain text or easily decoded formats” has been a recommended best practice for at least 25 years — and yet, software developers like the ones who built the Ashley Madison site are still making the same mistake. If these developers were building a physical building with this kind of sloppiness, the building would fall down and people would die in the collapse.

We’ve been telling ourselves for a long time that the virtual world is different than the IRL (in real life) world. We imagine that online, people will behave according to their better natures and will collectively create things that are better than ever. But software is fundamentally similar to soufflés: humans create both using commonly available ingredients. And all humans make mistakes. That’s OK, but we need to do what we can to prevent common mistakes. We also need to be aware that where there is technology, there will be fraud.

Technology is essential to our society, just like food or shelter. Let’s trust developers to do the right thing, like we trust chefs or architects to do the right thing. But, let’s verify as well. And let’s have some rules, enforceable ones, so that we can protect ourselves from both malicious and well-intentioned mistakes.

--

--

Meredith Broussard

Assistant professor at the Arthur L. Carter Journalism Institute of New York University & research fellow at Columbia University’s Tow Center