Software security myth #4: Software security is a cryptography problem
Q: Can I secure my software using cryptography? A: Cryptography is useful tool for securing data, communications, and code globs, but it’s no silver bullet.
Software security isn’t the same thing as security software. You can use a crypto library to add a security feature to an application, but that’s not the same thing as making an application secure. The liberal application of magic crypto fairy dust to your code will provide no security by magic. (In fact, the same myth applies to any particular security feature, not just crypto.) Software security needs to be built in from the ground up. That’s why cryptography makes the list of myths about software security best practices at No. 4.
Cryptography can be a useful tool when it comes to securing data, communications and code globs (among other things), but it’s no silver bullet. Why? you ask.
Magic crypto fairy dust
The idea that you can sprinkle magic crypto fairy dust all over a piece of software and it will then be secure is wrong. First off, security is a system property, not a thing. Simply adding crypto measures to your code is unlikely to make it secure. Additionally, cryptography is astonishingly complex to get right. Not only is the math difficult, but applied cryptography is filled with sneaky pitfalls that are easy to get wrong.
Cryptography can’t find or eradicate bugs and flaws, but sometimes it can temporarily obscure them and make life that much more difficult for debuggers and architects. Crypto can’t train your developers. And crypto even falls prey to penetration testing from time to time. To give you an example: If a SQL injection is found in your app that talks to an encrypted database, do you think encrypted data or plain text data will be returned?
Just as we’ve already discussed with perimeter security, software security tools, and penetration testing, crypto alone is not the answer. (Or more generally, any particular security feature alone is not the answer.)
There are two reasons for this.
- Most attacks against applications do not target security features specifically (and crypto is just another security feature). Most instead target defects in other parts of the application (bugs and flaws) in any part of the reachable code. Using however much crypto does nothing to fix these defects or to protect them from exploit. All SSL does is protect an exploit from prying eyes as it whizzes by. It might even allow an attack to sneak right by some firewalls.
- Applied crypto is designed to protect data, not the application that processes data. Data in motion between machines can be protected. Data at rest on a disk can be protected. But data being manipulated in real time by a running application is a sitting duck, or a running duck—well, you get the picture.
Is security a feature or a function? No.
Developers and software architects have been trained for years to piece out their work in terms of features and functions and often think by default that security is one of the two. The most common security feature in a developer’s mind is cryptography. That is, when you ask a developer to make their code secure, often the first thing they think of is crypto.
Software security is about integrating security practices into the way you build software, not simply integrating security features into your code. Identity management features, multifactor authentication, and PCI DSS compliance measures are all very useful and meaningful tools that shouldn’t be discounted. But at the end of the day, simply adding security properties such as these won’t magically secure the software.
There is no single “fix” to guarantee security. Achieving the most secure software requires carefully administered, step-by-step measures that take place strategically throughout the SDLC.
