Let’s look at five best practices for working with security in open source programming. When you write software, there’s a high likelihood that you’ll have to include some kind of security. Plenty of open source libraries are available to help you add security, but you have to do it right. Otherwise, you’ll be asking for big trouble later, which might include your client getting featured on the national news.
Don’t Do It Yourself
This is probably the single most important rule in dealing with security. Unless you are a certified security expert with lots of experience, do not try to write your own security code (Figure 1). Don’t do it. Period. Although you’re certainly welcome to start learning how to write security code and learn from the experts, until you truly reach the level of expert, don’t use your own security code in production. Instead, use the code created by the experts and tested by experts and the masses. For example, if you’re adding a login mechanism to your system, use a well-established library and implement the best practices encouraged by the library’s developer.
What about coming up with new encryption algorithms? That’s generally something you should again stay clear of unless you want to devote a career to it. Encryption algorithms are developed using advanced mathematics. It’s more than just shifting bits around and scrambling them. So, don’t delude yourself into thinking that you can come up with an encryption algorithm that’s as good as the others, unless you’ve actually been trained and mentored (read: doctorate degree or years of experience in the field). I certainly don’t mean to discourage young minds from exploring encryption; but if you’re going to work in the field of developing encryption algorithms, you need to first study under the finest minds around, learn what they’ve learned, and devote huge amounts of time to it.
Take home message for your open source project: Use well-established libraries, and don’t try to build the library or the underlying encryption code yourself. If you’re interested in building new security libraries, consider that an entire field that you can gradually learn.
Use the Right Security at the Right Time
Using the security encryption libraries is important, but you need to use the right kind of security at the right time. For example, some encryption is “symmetric” whereby a single key can be used to both encrypt and decrypt the data. Other encryption is “asymmetric” whereby a key has two parts: one that can encrypt and one that can decrypt. Other encryption involves creating what are called hashes. Some techniques involve combining multiple encryption approaches. It can quickly become overwhelming. Take the time to determine what you need when.
This is an area where too many programmers have failed, resulting in serious security breaches. Specifically, encrypted passwords need to be stored using a well-established technique of hashing and salting. Programmers have made the mistake using the wrong kind of security (e.g., a simple two-way encryption whereby entire password lists can be decrypted using a single key, once obtained) or of not salting their hashes correctly. The end result in either case is that, if the password file is obtained, somebody might be able to decrypt the entire thing. When this has happened at large organizations, it makes national news. (And, I imagine some people have lost their jobs over it.) Study the different types of security techniques and encryption and learn when to use which.
Obtain and Compile Trusted Libraries
Download source code for the library only from trusted sites and compile it manually. If you get the source from GitHub, make sure you’re getting the official version or an authorized fork (Figure 2). This is also a good chance to read user comments and bug reports. Are the users happy with the library? Are bugs being fixed? Is the library proving to be successful in large-scale projects? How old is the library? Is it an early version that might not be quite ready for prime time?
Then, take it a step further: Find out who is involved in the project and what their credentials are. Anyone can claim to write encryption code, but do you know for sure that the code correctly implements the algorithms? This is not an area where you want to slip. You need to find out who is creating the library and whether the creators are indeed qualified to be doing so. If you can’t find out who the creators are and what their qualifications are, move on to the next one.
Follow the Documentation
Good security libraries have good documentation. Read the documentation carefully and make sure you understand it. You want to follow it to the “T” without straying. In order to follow it, however, you must make sure it makes sense to you. If the documentation tells you to obtain a hash using a certain function, make sure that is in fact what you are doing. This is not always easy. Look at the sample programs and follow them carefully until you fully understand them. Compile the samples and test them out. Then, write your own test programs until you master the use of the library. Finally, after you fully understand how to use the library, you can use it in your product.
Eyes on Your Code
After you write your code, you need lots of eyes to inspect your code to make sure it’s right. When creating an open source project, this means enlisting plenty of people to help. If possible, try to get somebody from the security library to do a code review, and take any advice from that person seriously.
When you’re creating an open source project that uses the security code, you have an additional issue because other people might fork your code. Those people might not follow best practices and modify your code in a way that breaks it. Although you probably don’t want to restrict people from forking your code, you probably do want to put a stern warning in the documentation telling people not to fuss with the security portion of the code and that, if they think they found a problem, they should submit a bug report and possibly a pull request if they tried to fix the bug.
Conclusion
Working with security takes care. You don’t want a disaster to be the way you locate a bug. Follow the steps I’ve outlined here, but take them further: Read as much as you can about security best practices. I’ve only scratched the surface; for example, if you’re storing encrypted data in web cookies to maintain sessions, there are plenty of best practices published. If you’re storing encrypted user data that needs to be accessed quickly, again, follow the best practices. Stay in touch with the communities and be safe.
