In system development a “backdoor“ creates a way of bypassing normal authentication to allow access to a system. Secret backdoor credentials often exist deep in the thousands or millions of lines of code that make up a system. This is just one reason why building your own user management/authorization/authentication schemes into systems is a bad idea, but that is a topic for another time.
I was recently on an elevator with some people who apparently worked for a software company. I overheard something about how their support people use a backdoor in order to access the application. I thought that the practice of installing backdoors in applications was well known to be a very bad idea, and that the practice went the way of the NeXT machine. Perhaps I was wrong.
This bit of overheard conversation opens a Pandora‘s box of questions: Which applications have backdoors? Should my software vendor be required to tell me if the application has a backdoor? How many applications are out there that we don‘t know about with backdoors that were created by developers, either well intentioned or malicious?
Imagine if a popular home finance package, for example, had a backdoor. Even if it had been put there with the best of intentions, all it would take is one malicious individual with knowledge of the backdoor to destroy not only the software vendor but also the personal finances of millions of individuals.
NetSPI‘s application code review assessments include checking for backdoors. Given the small amount of application code that ever gets reviewed, let alone by a third-party security assessment like NetSPI’s, it is safe to assume that there are a lot of scary things buried in trillions of lines of source code out there.
My advice:
Developers: Don‘t implement backdoors. It is a very bad practice.
QA & Development managers: Include checks for backdoors in your SDLC.
Consumers: Ask your application vendors if there are any backdoors in their products, and get their answers in writing.
