Back Doors

Another temptation is to put in back doors in your code so that a customer service representative (for example) can get at secure data, even if the customer has lost a password or a certificate. With just the little extra effort it takes to put in a carefully controlled back door, you look like a shining hero, saving the customer from her own foolishness.

That's possibly the case. On the other hand, back doors are often poorly implemented and can give way to easy hacks. The result is a lot of wasted time and effort on security.

To illustrate this, we'll use the 100th Window Problem. Let's say your company has a large building with 100 windows that are all open , and you rush around locking them all before you leave for the day. Unfortunately, you actually lock only 99 windows, having overlooked one. Even if you have excellent locks and burglar alarms on all the locked windows, a thief can slip in the 100th window and make off with all your corporate goods. The more windows you add, the harder it is to make sure that everything is secure.

Generally speaking, there's no point in securing less than 100 percent of the relevant portion of your system. If you're going to do it at all, you must be committed to securing everything. It's better to offer your customers secure offsite escrow of passwords and keys than it is to build in back doors. That way, if they don't take you up on your service and they lose their password or certificate, they can only blame themselves .

Also, you're not saying, "By the way, our software is really secure, but we can break the security if you need us to." You're saying "We'll try to help you avoid costly mistakes, but our software is so secure that even we can't break the security." This is a better technical message and a much better marketing message.

Customer Support Shouldn't Sneak in through the Back Door

One customer of our enterprise-class software system was having trouble managing their database. Customer support was having trouble diagnosing the problem because our customer was unable to run the necessary SQL commands to diagnose the problem. They just didn't have the necessary skill.

One of my developers created a very clever solution. He wrote a program that could send an arbitrary SQL to another program installed at the customer's site. This program would apply the query to our customer's database and return the results to technical support. Once installed, it would periodically check for any commands, roughly every few minutes.

We sent this program to our customer. They installed it, and a short time later the customer support team resolved the problem. In fact, the solution was so well admired by both customer support and the development team that they lobbied hard to put this into the next release. I said, "No." The risk of creating an inappropriate command and sending it to an unsuspecting customer was simply too great. Even when intentions are good, you have to guard against back doors.

Luke